Minecraft Wiki talk:Projects/Redirect cleanup

Organizing the redirects once we decide what to do about them
Can we apply categories to redirects? What if we had a few categories:
 * and so on. Whatever categories we ultimately decide
 * and so on. Whatever categories we ultimately decide
 * and so on. Whatever categories we ultimately decide
 * and so on. Whatever categories we ultimately decide
 * and so on. Whatever categories we ultimately decide
 * and so on. Whatever categories we ultimately decide
 * and so on. Whatever categories we ultimately decide

It may facilitate the project -- though I'm also thinking of later benefits, such as:
 * There could be a maintenance page dedicated to uncategorized redirects (to decide whether they're good or not),
 * Several of those redirects, like 'english variant', 'historical name' or 'common name' redirects, should (probably?) not be used in wikilinks; wikilinks should use the in-game name. So if we had those in a category, or categories, those could be checked from time to time, in bulk, to see that they're not used in pages.  They would just be terms for the search bar.

Just thoughts. – undefined/undefined 16:42, 9 August 2016 (UTC)


 * Excellent idea, that will help to keep unnecessary redirects out after the project is done. – ᐸ  23:15, 9 August 2016 (UTC)


 * Support. I'm not entirely too sure about this, but Wikipedia uses templates on redirect pages (such as here), and it might help here as well, with the template adding the category to the redirect. -  19:43, 8 February 2017 (UTC)


 * Here's a mockup template design: -   15:51, 28 March 2018 (UTC)

Plural redirects
The style guide currently advises using link suffixes if possible to avoid needing extra redirects, but many plural redirects still exist.
 * Case for
 * Allows slightly more readable source text:  is easier to read than
 * Allows searching for plural terms


 * Case against
 * Isn't necessary for most links due to link suffixes
 * Is useless in search suggestions, making it more difficult to find pages

Feel free to add your own points for or against plural redirects.

I see 3 choices:
 * 1) Allow plural redirects
 * 2) Only allow plural redirects for plurals which aren't a suffix (e.g: "Wolves", "Blocks of Coal")
 * 3) Don't allow plural redirects


 * I vote for option 2. – ᐸ  23:37, 9 August 2016 (UTC)


 * I'm also in favor of #2, I feel it's in keeping with style guide so far, and I'm not sure people searching for a plural wouldn't just see the singular pop up, as they type. – undefined/undefined 00:43, 10 August 2016 (UTC)


 * I would also agree with #2, though I can see potential for confusion among new editors when making plural links. Basically, a lot of new users don't know about the plural link trick, so will likely try the formerly redirected version and see it as a redlink to create (which at best recreates a deleted redirect and at worst creates a duplicate article). – · 03:33, 10 August 2016 (UTC)


 * I also like #2; however, less experienced wiki editors may not know that link suffixes work. They're likely to either attempt to link to the missing plural redirect, or use a piped link (e.g., ). The former isn't hard to fix, and the latter isn't technically wrong – a bot can check for those periodically. I'm fine with getting rid of unneeded redirects, but be aware that this does make the wiki a little less friendly for new and casual editors. -- undefined 03:39, 10 August 2016 (UTC)


 * #2 pretty much seems like the obvious option. As such, that's the one I'm supporting. -  19:43, 8 February 2017 (UTC)


 * I would only support use of redirects for actual in-game item / block names, no plurals. #3 -  17:55, 17 February 2017 (UTC)


 * I am in support of #1, as I search for plural terms on a regular basis (it usually happens when I am searching for a list of monsters or status effects and forget to leave off the s.) I also have the habit of typing while looking at the keyboard, and rather quickly, so I wouldn't notice the singular option appearing most of the time. I know I am making assumptions here, but most of us in this thread are experienced users, and know not to search for plurals. However, a wiki should be for everyone, not just the experienced, and I'd imagine there are plenty of inexperienced users who also search for plurals, but never speak up (possibly because some of them don't have accounts yet.) If you look at the pros and cons of each side, the worst you're going to get with option #1 is extra use of storage space (I don't know how much of a problem that is here, but I would think it be a small percentage,) more redundant search suggestions, and a longer list of all pages on the wiki. The worst-case scenario for #3 is piped links, inconveniences for the inexperienced, and some of the redirect pages being created anyways, which could discourage new editors when the redirects are subsequently deleted. Option #2 would create a little bit of each issue, I'd imagine, while leaning more towards #3 because most English plurals are regular. The best-case scenario for each is that #1 is convenient, #3 cleans up search suggestions, and #2 is a bit of both.  18:25, 29 January 2018 (UTC)


 * Support #2 – They are not needed. They do not have to be linked to, and it should redlink when you link to one. New editors can just use pipelinks if they don't know how to add link suffixes. It is also confusing when you search for, say, "Torch", and you get both "Torch" and "Torches" as options. Singular is the one used ingame and should be the only option when searching. –    20:22, 29 January 2018 (UTC)


 * Support #2 because it makes the most sense to me. If people are missing the singular suggestion when typing the plural in cases like Torches, offering lenient support for that seems silly to me. No offence Sotuanduso. But if a plural like wolves exists for an article it's best to keep that kind of redirect. Without one, I'm not sure whether mediawiki would understand it enough to provide the singular article title as a search match. Besides that I could go for either way. I would just strongly suggest the consistency of just one option applied everywhere. – [ Jack McKalling ] [   ] 20:47, 29 January 2018 (UTC)


 * Strongly Support #1. I know this is different than what most other users say, but if you look at this wikipedia article, it clearly states that redirects are cheap. Also, remember that pages are never fully deleted. Everybody seems to think that just because a page can be linked to one way, that means there should not be a plural redirect. However, while this may be true, plural redirects are very important to visitors of the Minecraft Wiki who search for the plural version of an article. Otherwise, readers may think there is no page on that specific topic because there's no plural redirect. The stuff about the singular options popping up while people typing is not really true either. The wiki takes a few seconds for it to register what someone is typing, so if someone is typing at a normal rate or even quite a bit slower, the wiki won't take the time to register it and it will look like the plural page doesn't even exist.


 * Another argument could be that the singular page will likely show up when searching. However, this is not true at all for pages that have been created in the last 3 months (I don't know the exact number, but I know it's at least 3 months). Let's take the page turtles for an example, a plural redirect currently pending deletion. If that page were to be deleted and a wiki reader were to search for "Turtles," no search results would come up, and that reader is unlikely to figure out that there is a page about turtles. To be honest, recently I searched for a plural page and it took me forever to figure out the actual page, and I have been a major wiki contributor for a long time and know the redirect policy. Another thing is, even if the correct article in the search results come up, that's extra time for the reader to have to search for it. This is not a lot of time, but it's so much easier just to go ahead and make plural redirects.


 * Because of these reasons, I strongly believe that existing plural redirects should be kept and new ones should be made. There really is no reason why there shouldn't be plural redirects, even if the redirects were completely useless (which it's FAR from that). It would make wiki readers have a much easier time getting to pages, and it would not hurt the wiki in any way at all. So, I strongly support number 1, but I know that this is very unlikely to be true because of all of the users that support number 2.-- • 16:48, 23 February 2018 (UTC)


 * Basically, this video summarizes it all:


 * -- undefined 00:54, 5 April 2018 (UTC)


 * I suppose it's useful for direct searching, but the main issue is it cluttering suggestions. What we really need is a way to filter plurals out of the search suggestions. – ᐸ  04:32, 12 April 2018 (UTC)


 * Did you do something just now or recently? Plurals aren't showing in search suggestions anymore. –   |  04:45, 12 April 2018 (UTC)


 * That's just search/suggestions being totally broken, which has been an issue for awhile. For example: Nautilus Shell doesn't show up at all, nor the Nautilus redirect. And you'll notice results that are returned are outdated (version shown is from 3 years ago, when it was last edited at the start of the year). – ᐸ   05:17, 12 April 2018 (UTC)


 * Search has been fixed, and it still seems that plurals/redirects do not appear in search results unless they are the only results (for instance, searching for Nautilus doesn't include the redirect, but e.g. Entiti does give Entities). I'll try to find something that confirms this is indented behavior. --  23:19, 29 May 2018 (UTC)
 * Behavior actually seems to be more interesting than I first thought; a Special:PrefixIndex search shows that there are several things there... and that Nautilus core is a redirect. But only one redirect was included there, not all of them all going to similar places.  I'm not familiar with the mediawiki codebase, but I do see some code that tries to handle redirects in a special way, and test cases for that code (I think). --  23:48, 29 May 2018 (UTC)
 * Confirmed search is no longer an issue, at least if everything works fine. I created a somewhat excessive amount of test redirects over on the test Wikipedia instance.  Searching for   gives 5 results, all useful.  Searching for   gives 5 results, one of which is a redirect since "block of gold" is no longer included directly so instead Gold (block) or such is given.  Granted it's picking just one, and not necessarily the best one, but it's hardly a breaking issue. --  00:33, 30 May 2018 (UTC)


 * Also, I'm going to point out something about Wikipedia's redirects, now that the subject about hiding certain redirects when searching has come up. I don't know how exactly they do it - but based on experimentation, on Wikipedia, there will never be more than one redirect that goes to the same page that shows up in search, and if the actual target (main) page can be shown, that's what will be shown instead (if that makes any sense, which it probably doesn't). I'm just going to use as an example. There are 3 redirects to the page: Southern eagle fish, Southern eagle ray, and Southern eagle rays. If you search for "Southern eagle," only Southern eagle fish would come up, because I guess Wikipedia selects a random page that redirects to Myliobatis goodei, that starts with "Southern eagle." And then if you type in "Southern eagle r" all the way to "Southern eagle ray," the only redirect that shows up is Southern eagle ray, even though Southern eagle rays is also a redirect. It's not until you type the full-length "Southern eagle rays" that it actually comes up, because there is an alternative redirect to Myliobatis goodei that the system can use. On the other hand, if the same pages/redirects were on MCW, all 3 redirects would show up if the reader were to search for "Southern eagle," and both of the latter 2 would if they were to search for "Southern eagle ray."


 * So, if we could somehow get the search bar of Minecraft Wiki to function like that, that would probably be ideal. However, I'm not really sure how that could be done.--<span style="background-color:aqua;border: 1px solid"> undefined 02:36, 8 June 2018 (UTC)


 * I think the MCW search bar already works that way, which isn't surprising since we also use MediaWiki. Take for instance. There are 8 redirects to this page, all of which start with "0.24 (August". If I type that into the search bar, I only get "0.24 (August 4, 2009)" in the search results. (It happens to be the last match in the collating sequence, though I'm not sure it wasn't selected randomly.) Unless I misunderstood you, that's the ideal behavior you want. –  ( &middot; ) 04:39, 8 June 2018 (UTC)


 * You're right! Was that something updated recently? Well, now that that's the case, I really don't see how deleting plurals is going to help anything at all. For example, when you type "Grass Block," "Grass Blocks" doesn't show up. Same with "Torches" for "Torch." This also means that there's no point in deleting many other redirects, e.g. .--<span style="background-color:aqua;border: 1px solid"> undefined 15:14, 9 July 2018 (UTC)


 * Reconfirming my support for #1. Some of my reasoning no longer applies due to the fact that search suggestions have finally been fixed (\o/), but I still support it. First of all, if a person searches for a plural, it seems silly to me to make them have to search for the term instead of just taking them straight to the correct page. Second, new editors are clueless on how to link correctly, and it would be extremely annoying to have to fix every single edit made by someone who links like rather than s, otherwise having dead links showing up. Third, plurals are literately not harming anything at all. They don't clog up any search suggestions, and that's really the only reason why any redirects should be deleted. Try it for yourself - when you type Apple in the search box, Apples does not show up. Pokechu22, Auldrick, and particularly Sotuanduso did a great job of explaining the rest of my reasoning. Overall, this would mean fixing an absolutely ton of links, deleting many, many redirects, making sure newbies know how to link properly, making sure to fix anyone's edits if they link to a plural, practically no benefit... is it really worth it? So I still support keeping.--<span style="background-color:aqua;border: 1px solid">  undefined 00:34, 8 August 2018 (UTC)


 * Strongly support #1: my general opinion in this is that it's useful to have redirects for all cases. A particular note is for instance Entity/Entities cannot be written using the suffix syntax, but I support all such redirects just out of convenience and since redirects are cheap.  (as I mentioned before on the  section,  fits my thoughts).  --  23:19, 29 May 2018 (UTC)


 * I did a survey of online reference works to see if there was some kind of industry standard. Both Merriam-Webster and The Free Dictionary index regular plurals but score them low as progressive search results unless they're exact matches. Wikipedia behaves the same, provided a redirect page exists, and this seems to be the new default for MediaWiki since this wiki also works this way now. On the other hand, Encyclopedia Britannica doesn't index regular plurals, but scores progressive search results containing the plural term normally, and performs a full content search on them the same as it does any nonindexed input. In summary, it seems that only the most staid of online reference works expects its readers to know what used to be taught in Library Science: that index terms are normally singular. Since I'm an oldster, that seems obvious to me and #2 is therefore the most appealing. But as an editor, I feel my duty is to bow to the times and the expectations of our readers, so I support #1 because . – ( &middot; ) 01:18, 8 June 2018 (UTC)

Counterproductive project
Redirects may have links from other websites. It may be best if we keep the redirects. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 04:06, 27 February 2017 (UTC)


 * I'm quite happy to sacrifice ancient external links in order to make search suggestions actually usable, plus we can include a link to the real page in the deletion reason so any one that does end up there can still easily get to the right page, without it cluttering the search. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 04:17, 27 February 2017 (UTC)


 * Seems like a decent idea. If the original author of the linking site has abandoned work on the site for a long enough time, it's probably too outdated to be reputable/trustworthy anyway, and up-to-date sites will be able to fix their links easily enough.-  08:33, 27 February 2017 (UTC)


 * Adding on to this, redirects should never be used to support external links which are invalid in ANY case. Quite simply, there's no excuse for incorrect links on their part as the links are made. <span style="font-size:50%; vertical-align:middle; text-align:center;"> 13:05, 27 February 2017 (UTC)

Talk pages and user pages
Should we be able to edit talk page comments for the sole purpose of removing these redirects? It wouldn't change the functionality of the pages at all, so I don't see it as too much of a deal. -  07:43, 30 March 2017 (UTC)

On a similar note, could user pages be edited for the same reason? It feels a bit rude to edit someone else's user page(s), but then again it's their responsibility to take care of it; as such, they should be responsible for patching up any broken links. Helping out by fixing these up doesn't seem to be way too bad, but I'm kind of on the fence. Should this too be an allowable movement? -  10:11, 31 March 2017 (UTC)


 * I had a very similar discussion about template calls on the [//minecraft.gamepedia.com/Minecraft_Wiki_talk:Community_portal#Edit_other_people.27s_user_pages_for_maintenance_tasks.3F Community talk page]. As far as the editing of user pages goes, redirects can be treated the same way as template calls. The way I see it, the privateness of user pages should not supersede fixing maintenance issues, in case there is a lot of maintenance raised by these pages. The maintenance lists on special pages would clutter up, obstructing the mainstream.
 * I would recommended asking the owner of the user page first if they're active, and otherwise to leave the reason for your edit in the edit summary. – ( • • ) 19:57, 20 November 2017 (UTC)


 * In my opinion, this is about the contrast between form and meaning. Is the injunction against editing user pages meant to protect the wiki markup, or the meaning it represents? I think most people would say it's the meaning that's important. But if we interpret the injunction strictly under that view, the maintenance itself violates the user's right of ownership because it removes material the page depends on for its meaning. Obviously, we can't let that interfere with necessary maintenance, so repairing the damage by altering the user page markup is actually the appropriate thing to do. As long as it's done in a good faith attempt to restore its original meaning, the user should have no reason to object, and in fact should welcome the alteration. I think the injunction against editing user pages should be clarified to state that it's permitted to alter user pages to reverse damage done by wiki maintenance, unless the user explicitly reserves that right to themselves. – ( &middot; ) 02:15, 8 June 2018 (UTC)

Banner redirects
I suspect that none of the 600+ banner redirects listed here are necessary. Maybe they were created because a template used to link to them, but currently the redirects are unused and don't appear to serve any purpose. - (&#124;)  03:37, 25 April 2017 (UTC)


 * I have mixed feelings about these pages. On one side, they are indeed the names of items, just like Blue Bed and Acacia Fence Gate are, and reworking the entire Crafting template/changing all the entries on all the pages would be a bit of a hassle. On the other hand I doubt people would be searching for specific banners and would probably just type banner instead into the search bar. I say keep for now. -  12:16, 25 April 2017 (UTC)


 * I notice that the banner crafting usage template doesn't actually link to these redirects, they link directly to Banner (see below).
 * Is it true that these redirects aren't actually needed, due to some technique used in this template? If so, I definitely support removing the redirects.  Additionally, could this technique be reused across the board, so we could retire redirects like Blue Bed, Acacia Fence Gate, etc.?  Maybe, judicious use of what we already have in  could direct the crafting template to repoint 'Blue Bed' to 'Bed', and it wouldn't require the changing of any other pages?
 * The idea that just because it's the actual name of the item, therefore we should have a redirect to accommodate it – this doesn't feel very compelling when it comes to these color or wood-type "variant" items. I would rather we get rid of them.  It doesn't seem like it encourages good linking, and it is a source of search-result clutter. –  <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 16:23, 25 April 2017 (UTC)
 * The idea that just because it's the actual name of the item, therefore we should have a redirect to accommodate it – this doesn't feel very compelling when it comes to these color or wood-type "variant" items. I would rather we get rid of them.  It doesn't seem like it encourages good linking, and it is a source of search-result clutter. –  <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 16:23, 25 April 2017 (UTC)


 * I don't know anything about Lua, but this change seems to have had something to do with it. - (&#124;)  23:10, 25 April 2017 (UTC)

Ass
<div style="background-color: #efe; padding: 0 10px 0 10px; border: 1px dotted #aaa;">

The result of the discussion was delete the redirect.

This redirect to "donkey" could be deleted, since although it's a "correct term" I can't really see anyone using it. - (&#124;)  03:45, 25 April 2017 (UTC)
 * Agree that this should be deleted; the blank page should also obviously remain protected. Also by this logic we should have pages like "cock" that redirects to chicken, "bitch" that redirects to wolf, "pussy" redirecting to ocelot, etc. I don't see any circumstances where pages of this description would be used unless some 12 year old tries to get crafty. -
 * Agree. – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 16:24, 25 April 2017 (UTC)
 * Agreed. ―  22:10, 24 February 2018 (UTC)

Pages that redirect to mods
I've seen a large amount of redirects that do not begin with "Mods/", but redirect to pages that do begin with "Mods/". Should these be allowed? -  12:38, 25 April 2017 (UTC)

Also, on an extremely similar topic, how about servers - would these be in violation of Rule #5 as well as being useless redirects? -  12:39, 25 April 2017 (UTC)

Could we please stop adding deletion templates to plural redirects?
"Work in Progress: Don't take action until details are worked out," are the very first words on this project page. However, people are continuously marking redirects for deletion, despite the fact that no final decision has been made. As you can see at, I very strongly oppose deleting them, but right now I'm not talking about my opinion - I'm talking for the whole MCW community. Could we please stop deleting them until we've actually come to a decision?--<span style="background-color:aqua;color:;border: 1px solid black"> • 13:29, 22 March 2018 (UTC)
 * Also, I'd be fine with removing all the deletion templates myself if necessary - the pending deletion categories consists of mostly plural redirects, so I could just look through that category.--<span style="background-color:aqua;color:;border: 1px solid black"> • 13:31, 22 March 2018 (UTC)


 * They were mostly . I've cleared all redirect deletion requests so the deletion category is actually usable again. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 04:30, 12 April 2018 (UTC)


 * Projects have no special authority over their topics and can confer none on their members. That "Work in Progress: Don't take action", being on the project page, is directed at the project members, not editors in general, and it has no authority in any case: It's a request, not an edict. All editors, even project members, are subject to the rules and guidelines unless there is consensus to ignore them, and for guidelines that consensus should have a broader scope of discussion than a single project. It is perfectly appropriate for editors to request deletions in conformance with the existing guidelines. Trying to prevent that is disruptive to the wiki in that it stymies normal maintenance. So, could we please stop adding redirects for simple plurals in violation of the current guidelines, and claiming it's justified by a project that hasn't even decided what it wants to do yet? What you're doing gives the impression you're trying to load the wiki with a , so you can argue it'd be easier to change the guidelines than to undo the illicit work. – ( &middot; ) 21:10, 22 May 2018 (UTC)


 * So, basically what you're saying (if I'm understanding this correctly) is that the community has already decided that plural redirects should be deleted and that's what the policy is now. This is not really true, though. "Stop adding redirects for simple plurals in violation of the current guidelines" - I'm sorry but that's not accurate. As far as I can tell, the only discussion there's ever been on whether plural redirects should exist or not is on this page (please correct me if I'm wrong). Also, I don't see any kind of current policy or guideline that says that plural redirects should be deleted. About a month ago, information about the fact that plurals should be deleted was added to the style guide, with no discussion about actually adding it to the style guide, but this was actually reverted less than 2 weeks later by, with his exact words being, "There's been no consensus about plurals. The project page still literally says: TODO."


 * So basically, where I think you're going wrong is that this is in violation of the current guidelines. No - the PROJECT information was discussed long before this was added to the style guide (which I assume is what you mean by "policies and guidelines"), and it only remained on the style guide for a short time, before it was reverted for "no consensus," with the edit summary actually referencing the project page. I definitely don't think this would be a case of fait accompli. Also, I apologize if this sounds rude or anything (I don't mean for it to), but I just think in this case it's important to explain my reasoning clearly, which I hope you don't take as offensive.--<span style="background-color:aqua;border: 1px solid"> undefined 22:07, 22 May 2018 (UTC)


 * You're right, I was wrong about the guideline. Let me explain. I've been stewing about this since May 4, when  my edit requesting deletion of . Immediately after, he  the paragraph from the Style Guide, but I never saw that: Practicing due diligence, I had already researched the guidelines on redirects, so from my point of view, I "knew" that plural redirects were not allowed, and the way I interpreted Majr's edit summary ("Undo revision 1205646 by Auldrick (talk) was added without consensus") was that my edit lacked a required consensus. I realize now he was referring to the false guideline I cited in my edit summary, but at the time I thought he meant that this project sat in judgment of all edits done to redirects.
 * I then came upon this topic, which reinforced the impression that you were usurping control over edits to redirects, by contravening what I believed was in the style guide. I was frankly incensed, and was unable to express myself rationally and appropriately, so I left it alone until now. I realize now I was mistaken, and I'm sorry if some of my lingering ill temper showed. Please forgive me.
 * If there's a lesson to learn here, perhaps it's that we need a bit more oversight over the few guidelines we do have on this wiki. How is it that "official" pages like the Style Guide can go two weeks without a seriously improper edit being reverted? Does nobody watch such pages? But these are questions for a different project to address. – ( &middot; ) 01:30, 23 May 2018 (UTC)

Reduce scope
Since search suggestions are broken anyway, perhaps we need to reduce the scope of this to just getting rid of uncontroversially useless redirects (fan names, old nonsense page names (disambig format)), and categorising existing redirects in order to make it easier to determine the usefulness of existing and future redirects (In other words: lets ignore plurals because there seems to be no clear consensus, and this project has been stalled for a few years because of it).

Then in a bright, utopian future where search suggestions actually work, we can discuss either getting rid of less useful redirects, or just find a way to hide them from being suggested. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 05:16, 4 May 2018 (UTC)

Redirects to tutorials
I noticed recently some redirects to tutorials from the article space were marked for deletion (I assume as part of this project). I personally think those are fine if its a common search term, as some Minecraft terms are just not coverable outside of tutorials, but still are notable enough that they will be searched. Leaving out the redirect makes it more likely for a new user to make a new article on it instead of improving the tutorial.

On the opposite side, I am in favor of removing redirects to Mods from the article space, as this wiki keeps to non-modded content in general. I would say the same with community programs as well, they can be covered as subpages where they are now but should not have article space redirects.

I'll propose something more formal on the style guide after getting a few more opinions here. <span class=nowrap>– · 16:56, 26 May 2018 (UTC)


 * I agree about the tutorials - I see no problem with keeping the tutorial redirects if they are common search suggestions. As for the mods and custom servers, I honestly think all mod pages should be deleted from this wiki long-term, this has been an ongoing discussion . For short-term, I definitely think that all redirects that are, e.g. Bukkit/"Certain item", are completely unnecessary - I can't see anybody searching for that. Ones that name the custom servers alone (e.g., Bukkit) seem to be likely search terms, but that doesn't mean they should be kept.--<span style="background-color:aqua;border: 1px solid"> undefined 17:26, 26 May 2018 (UTC)


 * I'd only keep the tutorial redirects that people would be most likely to search for, such as the more general/broad ones. -  17:31, 26 May 2018 (UTC)


 * I'm in favor of deprecating mod content on this wiki, which means expunging non-mod redirects to mod titles. We now have a searched terms dashboard, which indicates non-modded content is strongly favored on this wiki (total opposite of the situation on the Russian wiki BTW). For context, treating mods as a separate namespace has been proposed in the past; we can just do something like what Wikipedia does with cross-namespace redirects (or close to that). I support MinecraftPhotos4U with regard to tutorial redirects. -- 17:40, 26 May 2018 (UTC)
 * Pardon the interruption, but what is this "searched terms dashboard" you speak of, and is it available to registered editors? – ( &middot; ) 19:20, 26 May 2018 (UTC)
 * It's more accurately called "search log", it's part of the upcoming "admin dashboard" project, and thus only available to administrators. It's also in early beta and has numerous issues. -- 19:22, 26 May 2018 (UTC)


 * "as part of this project" Nothing is being done as part of this project, as actually defining the project is still a TODO and explicitly says not to take action. Anyone doing anything with redirects is doing it independently, and frankly I'm getting sick of it cluttering up pending deletion, and forcing admins to either have to delete them or repeatedly revert 's edits. Just stop it. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 02:52, 27 May 2018 (UTC)

What redirects do we consider for deletion?

 * See (please add for each redirect the reason why to delete, and do not create a contentless page)

To continue a discussion on the discord channel. There are a lot of redirects that are using delete or speedy delete, and before these can actually be deleted, we need to get consensus on which redirects are actually a candidate for deletion. Some redirects use alternate spelling or capitalization, others may have a questionable reason for deletion. Either way, as it currently stands, the style guide on these points is not clear enough. Maybe we could discuss an update to the style guide after this, but first we need consensus on each individual case.

Please help me create the above link, to summarize all redirect pages that we consider for actual deletion, and add the reason why so, to each individual one. Not just e.g. "incorrect capitalization", because there is no consensus on what is correct yet either. – <span class="plainlinks" title="View User PROfile">[ <span class="gamepedia_pro_user">Jack McKalling ] [   ] 22:51, 28 May 2018 (UTC)


 * My opinion is that redirects for typos/common alternative names (e.g. &rarr; )/plurals and short names are perfectly fine and are an intended use of the redirect system.  On the wiki, the ones for short names/plurals are fine to be used in articles, but the others probably shouldn't.  I see no reason to delete a redirect if it falls in any of those categories, even if it's not the "correct" name for the thing that it's being redirected to, and I see no reason to edit articles to get rid of links to redirects in most cases ( mirrors my thoughts more or less).  Wikipedia does have the  system, so that different redirects can be marked as ones for typos/whatever; that may be a useful thing to have here too. --  16:07, 29 May 2018 (UTC)

Current deletion category
And... the deletion category is getting enormous again. I know there's the discussion going on above, but for short term I think it will be much easier to just go through the pages that are currently in the deletion category and decide which ones to keep and which to delete. Here's a tentative list:


 * 1) "Bukkit/" redirects
 * 2) Strange formatting with parentheses, e.g. Iron (Ingot) or Nether Wart (block)
 * 3) Possibly unnecessary specifications, such as Observer Block
 * 4) Irregular formatting with dashes. These used to be helpful for BlockGrid, but now Majr's changed all of the block grids correctly, so the redirects are no longer necessary. However, they could be helpful if users are still used to the old way of doing block grids.
 * 5) Alternate capitalization redirects that shouldn't be linked to. Obviously, stuff like  or  are different because they could likely be links
 * 6) Irregular formatting for files such as File:Diamond (Ore).png and File:Leatherlegs.png.
 * 7) Talk pages of deleted pages, that only contain, and have only ever contained, a simple redirect
 * 8) Talk pages of deleted pages but that are full of content/topics, or have non-trivial history

Here's my opinions on everything:


 * 1) Delete. Unnecessary, and could be confusing to readers.
 * 2) Delete. Very unlikely search terms, and don't seem useful.
 * 3) Neutral, leaning towards delete. I'm more on the fence about these. Some of these should be deleted, but I've heard people refer to Barrier Blocks (which is not a redirect yet, btw) and Observer Blocks. I've changed my mind after thinking about this more and listening to other's opinions: Weak keep, almost neutral. I do think these could be possible search terms, and I don't really think they're hurting anything. I do think depending on the circumstances, though, some of them may should be deleted.
 * 4) Neutral, leaning towards delete. Definitely never going to be searched for, and incorrect block grid use. However, I have seen users use dashes for block grids several times, and even though it's incorrect, it could be useful.
 * 5) Delete, as searching <span title="I swear I had added these extra 3 words, but somehow they weren't there when I posted, so after this post had already been replied to I corrected it">is not case-sensitive  - however, I would definitely have reservations here. If there's any chance at all that anything could link to it, do not delete. I would say any alternate capitalization directly for pages about in-game features should never be deleted.
 * 6) Delete. Absolutely no reason to have these.
 * 7) Delete. No reason to keep these.
 * 8) Neutral, leaning towards delete. I do feel it is a bit strange deleting a page that has thousands of bytes of important conversations.

It would be helpful to get other's opinions on this, so that I can attempt to clean out the deletion category some more.--<span style="background-color:aqua;border: 1px solid"> undefined 15:55, 18 June 2018 (UTC)


 * My opinion is Delete for the Bukkit/ redirects, Delete for the redirect-only talk pages, no opinion on the files, Keep for all others as I don't think it's _necessary_ to delete them. --  16:10, 18 June 2018 (UTC)


 * 2, 4 6 and possibly 5 are obvious Style Guide violations (since it forbids bad formatting) and should be eligible for deletion regardless, and 1 and 7 seem extremely useless. As for 3, while they are commonly used terms, you can usually hear many types of block referred to as _____ Block at least once, which would lead to a huge list of unneeded redirects, so these should probably be deleted as they don't harm linking and searching should provide the correct result anyway. As for 8, only delete if the amount of conversation is not sufficiently large enough to be considered important enough to keep. -  16:31, 18 June 2018 (UTC)


 * Opinion: 1, 2, 4, 6, 7: delete as per provided arguments; 3, 5: keep/delete on a case-by-case basis only; 8: delete immediately if the talk page has no information which is significant after deletion, otherwise move this information elsewhere and delete. -- 07:29, 19 June 2018 (UTC)


 * - what precisely would you consider to be "no significant information" or "sufficiently large enough to keep?" And AttemptToCallNil, do you have any specific place where you think significant information on orphaned talk pages should be moved to?--<span style="background-color:aqua;border: 1px solid">  undefined 12:15, 19 June 2018 (UTC)


 * If the discussion is solely relating to moving/deleting the page, or there aren't many sections, it can be deleted. If there are two or more sections discussing the content of the page, it could be kept. -  12:36, 19 June 2018 (UTC)


 * I consider significant information on a talk page of a deleted page to be the discussion that led to its deletion, as well as any topics that are referred to or could be referred to within that discussion or elsewhere. For instance, consider a (not very realistic) example of a mainspace page "Ideas for Minecraft" which was intended by its creator to serve as a community-editable repository of ideas about Minecraft which could be implemented by the game's developers. In this example, the structure of the talk page is as follows:
 * In topics 1 through 5, new ideas are proposed by users and discussed. Neither of these topics contains any information beyond wiki users collaboratively inventing new gameplay elements.
 * In topic 6, a user proposes to delete the page as unencyclopedic. The result of the proposal is to keep that page on the basis that no wiki rules prohibit it.
 * Topics 7 through 9 are like topics 1 through 5.
 * In topic 10, which starts like topics 1 through 5, a user starts behaving disruptively. Just their behavior in that topic becomes sufficient grounds for a long-term block.
 * Topics 11 through 13 are like topics 1 through 5.
 * In topic 14, another user proposes to delete the page while providing a number of reasons. Topic 6 is referenced. This time, however, the result of the proposal is to delete that page. In addition, a subtopic (14.1) of topic 14 contains another proposal to prohibit the placement of user ideas anywhere on the wiki, including in their userspace; this proposal also passes.
 * In this case;
 * Topics 1 through 5, 7 through 9, and 11 through 13 are not significant, given they discuss material which can no longer appear on the wiki due to the results of discussions in topics 14 and 14.1.
 * Topic 10 is significant (and possibly has significant history), given that it provides context for a long-term block.
 * Topic 14 deals with the page's deletion and the deletion is not a result of simply violating wiki rules (which would just be linked in the deletion reason), so this topic is significant. By extension, topic 6 is significant because topic 14 references it.
 * But consider the following deviations from the example:
 * Sometime after topic 6 was closed and before topic 14 was opened, wiki policy was modified in a manner which made deleting this page not require prior discussion. This would also cause topic 14.1 not to appear on the talk page. In this case, topic 14 has a speedy resolution fully explained in the deletion reason, so topic 14, and by extension topic 6, is no longer significant.
 * The disruptive user's actions in topic 10 are such that they warrant reversion and revision deletion. In this case, the topic may no longer be significant because the context for the block (the user's actions) is no longer visible to regular users.
 * -- 13:50, 19 June 2018 (UTC)


 * I went ahead and deleted the Bukkit/ redirects - this has been brought up multiple times and there seems to have always been lots of support to delete them and no opposition at all. I'll probably wait for more responses before deleting most of the others, although I think it's pretty clear that the talk page redirects of deleted pages could probably go as well.--<span style="background-color:aqua;border: 1px solid"> undefined 14:06, 19 June 2018 (UTC)


 * {{{ping|Madminecrafter12}}, I encourage you to and follow your best judgment on what to delete, based on the rules as they currently stand. When we made you an administrator, it was a vote of confidence in your judgment on such questions. I understand that you don't want to appear power-drunk, but it's not like the decisions you make can't be reversed later if the wiki ever decides on how to change the rules. In fact, being bold is the best way to spur the discussion to a conclusion, because many editors (like me) are more reactive than proactive. The measure of an administrator is his ability to get the wiki's business done. For him, it's better to make mistakes and reverse them later, than to avoid them by moving at a snail's pace. –  ( &middot; ) 14:42, 19 June 2018 (UTC)


 * I definitely appreciate the confidence, Auldrick, and while I do think community consensus is important in circumstances - I agree that with so many redirects in various natures, we really can't discuss every single one, and a single administrator's decision may have to determine what to do in certain circumstances. One reason for this discussion is because, as you can see, I'm not so sure about some of the redirects, so it would be nice to see what the community thinks. I'm pretty confident about deleting redirects that fall under the scope of #2 and #7, so I do think I'm going to start deleting some of those (especially #7, as they seem to have unanimous support) - I still would like to hear other opinions about the rest, though. Again, thanks for the confidence. :)--<span style="background-color:aqua;border: 1px solid"> undefined 14:55, 19 June 2018 (UTC)


 * Well then, I'll give my opinions on your list.
 * 1. Delete. I think that's also unanimous.
 * 2. Case-by-case. I see the examples you gave as useful disambiguators in a list of search suggestions, but that's only because the game uses an ambiguous name as a block name. That's not very common, so I might prefer deleting others.
 * 3. Keep per . I'm actually surprised about, which I've only ever heard called "Barrier Block".
 * 4. No opinion, as I don't understand the issue with block grids.
 * 5. Keep as harmless, or perhaps case-by-case since you give exceptions.
 * 6. Delete, as File: pages should not contain text, period.
 * 7 and 8. Case-by-case, based on whether the discussion might have value if the page were recreated as either a redirect or an article. Default to Keep.
 * – ( &middot; ) 16:23, 19 June 2018 (UTC)


 * My input:
 * 2. While I think Auldrick was right to point out that these may have disambiguation value, I think practically speaking, that set, it can all be deleted. "Iron (ingot)" is unnecessary, as simply searching "Iron" brings up both "Iron (ingot)" and "Iron Ingot". And when you search "Melon" you don't need "Melon (seed)" as a result. And so on for all of them.
 * 3. Anvil block seems like delete because it's not a search term, Observer block seems like keep because it'd be a common search term. What are the other "specifications" you had in mind?  This seems like case-by-case.
 * 4. If Majr has fixed the BlockGrid issue, their purpose is gone, and they should be deleted.
 * 5. I would go through and delete them until I found a compelling reason I absolutely can't delete one. Style guide.
 * 6. Delete.
 * 7. Delete.
 * 8. Since we're worried that we really might want to consult these pages in the future, why not just sit them someplace like, that way they're not just sitting out there, orphaned, hungry and alone? They'll have a proper place which indicates why they're being kept.


 * If you would be so kind as to formalize your decisions here (and other deletion decisions you've made) as a proposal to amend the style guide, on that talk page, I'm sure we would be ready for such guidelines. –  |  19:13, 19 June 2018 (UTC)


 * - it appears that the search suggestions are different now, so now typing "Iron" does not show both, only shows "Iron Ingot." Currently, it seems to be that a redirect will show up as a search suggestion only if the target page can't show up OR there's not another redirect that shows up. I'm not sure if this is something that was recently changed, but it seems like deleting redirects isn't as important with this being the case. The only reason shows up is because it is currently pending deletion - if it were just a redirect it wouldn't show up when one would just type "Melon."--<span style="background-color:aqua;border: 1px solid">  undefined 21:47, 19 June 2018 (UTC)


 * much of the unused #6 files in the deletion category, as this seemed to have a lot of support and no strong opposition. Probably going to delete a few more later today.--<span style="background-color:aqua;border: 1px solid"> undefined 14:45, 3 July 2018 (UTC)


 * Why not delete them all, though? None of them are linked to by any mainspace pages, and if the fact that they are linked to at all is a problem I might be able to fix some of those. -  11:44, 4 July 2018 (UTC)


 * Not sure what the rush is with deleting these. They're not actively harmful, just not helpful. And I'm pretty sure I deleted all of the unused file redirects that violate the style guide. Note that I didn't delete the unused file redirects that are a common alternate name; only the ones that have irregular formatting or are against the style guide in some other way. Also, imo, just because something is only linked to by user pages or translation pages does not mean it's not important, and I definitely think the same for mod pages (see ). Feel free to let me know if I missed any unused file redirects, but I'm really not sure about deleting any that are used at all.--<span style="background-color:aqua;border: 1px solid"> undefined 14:18, 5 July 2018 (UTC)

Reviving this project
Over a year ago, this project to clean up redirects died out while still discussing which redirects to keep, and which ones to delete. A few months ago, the UCP update happened, and the search engines broke. Some of the problems are documented here. &#8212; Blockofnetherite Talk Contributions 20:21, 11 December 2020 (UTC)

(bad) Changes to advanced search

 * Generally broken overall, (much) worse than Wikimedia search
 * "...it doesn't suggest the redirect when typing in the search bar, but instead the target page of the redirect. For example, typing 'Warden' doesn't suggest the redirect Warden, but instead Caves & Cliffs. This means a user trying to find information about the Warden would have to scroll to the Caves & Cliffs § Warden section, while the Warden redirect would have gone to that section automatically."

&#8212; Blockofnetherite Talk Contributions 20:21, 11 December 2020 (UTC)
 * One of the greatest issues, if not the greatest: The search engine is now case sensitive (it used to not be case sensitive). This means that before, it was unnecessary to create a redirect Iron Golems because it used to be Iron golems. But now, uppercase is no longer redundant to lowercase.
 * Cannot create pages with the search engine Fixed.
 * Can see advertisements with Gamepedia PRO in the new search engine Fixed.
 * A lot of other issues I did not put here, feel free to add more.

Most likely keep
I doubt there would be any major valid opposition to keeping these types of redirects (or creating new redirects that follow these criteria): Exact names used in the game (or used to be an official term (ex. Notch Apple, or historical terms like Stained Clay), incredibly common alternate names, common link targets, names without diatrics (ex. Adrian Ostergard), and so forth.

Plurals?
Should we keep plurals, as discussed in the previous years? I will go back to the three options.

Options
Blockofnetherite Talk Contributions 20:21, 11 December 2020 (UTC)
 * 1) Keep all plural redirects
 * 2) Pros: Will not break any internal or external links
 * 3) Cons: See above arguments. Not 100% sure if these apply to the current post-UCP search that we have now.
 * 4) Only delete redirects which do nothing except add the letter s. For example, Zombies, Rabbits. Plurals that would not count would include Wolves or Tutorials/Defeating withers (because   would be grammatically incorrect, despite adding s to the end, the word “the” would be removed).
 * 5) Pros: See above arguments. Again, not 100% sure if these apply to the current search we have right now.
 * 6) Cons: May break links. Internal links can be resolved with Special:WhatLinksHere, however, external links may break. One example of external links breaking would be many pages on the Wurst Wiki (a wiki which documents a client-sided minecraft mod.) Pages there, like this page has links that go to pages like ,  , and   . There are probably much better examples than this wiki, but breaking external links is generally a problem.
 * 7) Delete all plural redirects
 * 8) Pros: Also see above arguments on other topics
 * 9) Cons: basically the same cons as above, but at an even greater scale.


 * I'd support another option: Having only lowercase plural redirects allowed, so no to "Grass Blocks" and yes to "Grass blocks". Dhranios (talk) (Join the wiki videos project!) 19:54, 11 December 2020 (UTC)
 * In my opinion, not a bad idea. Just pointing out (although I think you already do), that due to UCP, the searching is now case sensitive. But at the same time, it shouldn't be as devastating to break any possible external links to any redirects like "Grass Blocks," as the Wurst wiki I stated above points to "Grass block" instead of "Grass Block." Blockofnetherite Talk Contributions 21:06, 11 December 2020 (UTC)

Alternate names invented by YouTubers?
Should we keep those? Remember to keep in mind how we officially document many alternate game terms, like “Butter” in Tutorials/Game terms. What do you guys think? Blockofnetherite Talk Contributions 20:21, 11 December 2020 (UTC)


 * I really think we shouldn't allow this, as it's just inviting anyone to call something a weird name in a video, and use it to say "it's an alternate name!"... Dhranios (talk) (Join the wiki videos project!) 19:54, 11 December 2020 (UTC)

So what do we do?
Now we just need to discuss exactly what redirects should be useful and change the style guide. Any thoughts? Blockofnetherite Talk Contributions 19:24, 11 December 2020 (UTC)