Wikipedia talk:Categorizing redirects/Archive 2

Archive 1

Archive 2

Archive 3

Category:Super Smash Bros. fighters

In 2008 when many character articles were merged, there was some debate whether Category:Super Smash Bros. fighters should be left on the redirects.(The category had about 30 articles and 15 redirects.) While some argued that no redirects should have categories, others pointed to this guideline, and deciphered that it says this is allowed. So it stayed on the redirects for for over two years, with a few reverts, and now New Age Retro Hippie (talk · contribs) has removed it from all the redirects with the "categories should not have redirects" rationale. I just want to know what exactly the guideline reccomends for this situation where most of the characters in the category have articles, and around a third are in character lists.
I think that this guidelines states that if the category is to be complete, then the category goes on the redirects, not the lists. I think the real question is whether or not the category needs to be completed. _Blake ^{(Talk·Edits)} 01:37, 22 March 2011 (UTC)

I say IAR, and just keep all of them. I know Wikipedia isn't supposed to be the entire repository for all things, but this is Super Smash Bros. fighters. This needs to represent all of the characters in the series as reflected in the table on the series page. Sincerely Subzerosmokerain (talk) 02:18, 22 March 2011 (UTC)

Why? We don't even have categories for similar franchise fighters such as the Capcom Versus games. Like I've said, the categorization of these characters is tumultuous without ignoring this rule. - The New Age Retro Hippie used Ruler! Now, he can figure out the length of things easily. 03:48, 22 March 2011 (UTC)

And that's the precedent I was [not] looking for. This category seems out of place to me for Wikipedia; I'd almost call it a trivial categorization, aside from the fact there is a clear reason it exists. --Izno (talk) 18:25, 22 March 2011 (UTC)

I don't get the argument against categorizing the redirects. Let's forget about the guideline (it's ambiguous at best) and just ask what makes most sense for the reader. I couldn't care less about the Nintendo fauna but let's face it: the articles that are currently in the category are here to stay and should be categorized appropriately. The redirects are also here to stay: I don't think an RfD for King Dedede would last more than a few hours. Given that state of affairs, why should we leave out the redirects? To most readers interested in the topic, a category page that's missing King Dedede will be viewed as "those idiots forgot King Dedede" not "I see they were smart enough to include only characters which are otherwise considered sufficiently notable to have their own article". (The latter is made even more unlikely by the average age of readers interested in this category) I could perhaps see an argument against categorizing the redirects if we had a decent list article that the introductory sentence of the category could point to. This isn't the case. Pichpich (talk) 20:28, 22 March 2011 (UTC)

Usefulness is not a good enough reason to do something. Giving categories to these redirects implies some sense that they are notable, when they simply are not. Where is the failing in the list of characters? Heck, the list is MORE useful, as it has more characters than the category. The fact of the matter is that we really ought to be discussing the deletion of the category if anything as completely redundant to the list. - The New Age Retro Hippie used Ruler! Now, he can figure out the length of things easily. 21:26, 22 March 2011 (UTC)

Usefulness is the overarching principle behind the creation and maintenance of categories. A redirect appearing in the category does not magically confer it an aura of notability. To the casual reader, the entry is just there: he can click on it and he'll end up at some useful place. Pichpich (talk) 22:57, 22 March 2011 (UTC)

Redundancy is not a rationale for deleting it. Some readers/editors like lists, while some like categories. Often, both are used. EX: List of Nintendo 3DS games. Is the category redundant to the list? No. They help different people for different reasons. I think the category should go back to what it has been for the past two years, and having the redirects listed, because it is an easy way to find information on all the characters. How would you go from Ganon to Ivysaur? There isn't a template on the page. Clicking the link to SSB, and then scrolling down to the characters section, and then clicking the link to the character list takes way too long. The category is an easy way to link all the characters, and their location on Wikipedia. _Blake ^{(Talk·Edits)} 01:38, 23 March 2011 (UTC)

I think the issue is the category, and the preferable approach would have been to nominate it for deletion. Which can still be done, but must now include the history of events. Ham Pastrami (talk) 02:33, 23 March 2011 (UTC)

Categorising the Discussion page of an article

Last month, I posted a concern at the main Redirect guideline page here: [1]. Now upon consideration, I may have been too WP:BOLD in adding a third item to the guideline Wikipedia:Redirect#Categorizing redirect pages. The issue here is that the categories of the Talk:Tobey Black are for an article and not a class=Redirect page. I'll post a follow-up note at Wikipedia_talk:Redirect about my concerns and explicitly state that the change of the article to a redirect was an effective deletion of the article with no disscussion/notice. Isn't some sort of mention regarding discussion/talk pages needed in this guideline? Thank-you. Argolin (talk) 02:44, 27 March 2011 (UTC)

Category:Redirects from Unicode characters

A few questions have arisen at Wikipedia:Bot requests/Archive 43#Redirects from Unicode characters regarding just which pages should be in Category:Redirects from Unicode characters:

• Should only mainspace redirects be included, or should pages like WP:€ also be included in the category?
• Should "abstract characters" that are represented by more than one code point (i.e. a base character and one or more combining characters) be included or excluded? These are P̌, Β̞, D̰, D̬, D̥, D̤, J̌, R̝, N̈,  ̲, T̈, H̱, Λ̊, T̪, 0̸, ɪ̵, Ŋ̃,  ̲h, Ǝ́, X̱, Ю́, D̪, Y̨, Ą̊, Ǫ̈, Ą̈, Q̊, N̪, B̪, P̪, X̧, M̧, Y̧, O̧, Þ, Ʃ̧, Ʊ̧, M̄, N̄, R̄, S̺, U̴, and ɑ̃.

And since we're here,

• Should a bot actually do this?

Thanks. Anomie⚔ 17:33, 23 September 2011 (UTC)

Hmmm, should that Cat be subordinate to something more general, such as Category:Unprintworthy redirects? Looking further afield, Category:Redirects_from_titles_without_diacritics reflects considerable prior effort. LeadSongDog come howl! 18:21, 23 September 2011 (UTC)

Unicode characters are probably unprintworthy redirects, I agree. I don't see how Category:Redirects from titles without diacritics is related here.

I think a bot should do this, because any proposed definition of "Unicode character" can be used by a bot to quickly and consistently categorize the redirects. Consistency is a big problem when all human editors interpret the purpose of the category differently. Gorobay (talk) 20:23, 23 September 2011 (UTC)

Cause of death cat on redir pointing to band

If a person is not notable enough for an independent article, but has a redir to the band he was a member of, is it appropriate to tag the redir with a cause of death category? I can't quite tell from the main page if this is a good or bad thing. --SarekOfVulcan (talk) 20:00, 22 October 2011 (UTC)

• The target of the redirect should ideally be to a specific section in the band article about the member, and there should be sourced info about cause of death. Occuli (talk) 20:08, 22 October 2011 (UTC)
  • On reading the band article more closely, it appears it was a solo project. I'm confused. Lucifer (rock band) --SarekOfVulcan (talk) 20:23, 22 October 2011 (UTC)
    • Hi. I'm commenting here as Joe Faust has asked me why the two redirects no longer appear in the hang gliding deaths category. User:Ahunt removed them, as s/he felt, probably rightly, that they were not allowed by WP:RCAT. Thing is, if Denys Irving is Lucifer (rock band), then I believe Wikipedia:Rcat#Redirects_whose_target_title_is_incompatible_with_the_category might be met, as I expect Irving was not hang-gliding as Lucifer on that fateful day, but as himself, and so should be in the hang gliding dead people category, one way or another. Shawn in Montreal (talk) 13:20, 23 October 2011 (UTC)

Sorry I didn't realize this was up for debate, thanks for the note on my talk page. I removed the two cats because they were on redirect pages that redirected to a company and a band respectively. Neither the company nor the band was killed hang gliding. These really should not be on redirect pages as it looks like trying to pad out the category and make it look more significant than it is for numbers. It also runs afoul of Wikipedia:Categorizing redirects and was just misleading. These could be added back if actual biographies of these two people are written. - Ahunt (talk) 13:30, 23 October 2011 (UTC)

I agree with Shawn in Montreal - this is a text-book case where Wikipedia:Categorizing redirects does apply as Lucifer (rock band) is mostly about Denys Irving. The redirect should be categorised exactly as if it were the article Denys Irving (using the info in Lucifer (rock band)). (I am not however in favour of keeping Category:Deaths by hang gliding.) Occuli (talk) 13:40, 23 October 2011 (UTC)

Actually, the article is more than a little confusing. I'd be tempted to move the article to Lucifer (rock musician) since it seems that despite the uncertainty about who Lucifer was, it was always presented a solo project. And if the article is moved to that or a similar title, then I don't really see how this is any different than Lady Gaga or any other artist known primarily by their stage name. Pichpich (talk) 01:33, 24 October 2011 (UTC)

Redirect templates contiguously on the same line?

Why should redirect templates "be placed contiguously on the same line as the #REDIRECT"? I only recently learned about this. Unfortunately, over the years I had added a large number of redirect templates improperly. I have never noticed an issue arising from it however. In any case, merely having them helps explain why the redirect should exist in the first place. Jason Quinn (talk) 04:43, 11 March 2012 (UTC)

That restriction was removed in January 2006 (in r12339); the documentation here should be updated (unless there is another reason besides the old technical restriction?). Before January 2006, all wikitext in a redirect page after the first newline would be completely ignored (including templates and category links). Anomie⚔ 16:36, 12 March 2012 (UTC)

I can't think of another reason, so I updated that part of the text (Note 1). Other parts of the text seem unnecessary as well, e.g. setting the start of the sort to "{" or (most often) "}" ; I don't remember seeing that in my six years here. The {{PAGENAME}} stuff seems unnecessary too. Can we remove both those notes? – Fayenatic L (talk) 17:24, 12 March 2012 (UTC)

Thanks for the replies. It's good to know I wasn't adding errors and ended up getting the documentation improved. Cheers, Jason Quinn (talk) 18:33, 12 March 2012 (UTC)

Biography name sorting

Would using redirects to provide alternative sort keys for biographical articles be appropriate? Take Yingluck Shinawatra, for example. Thai people are known and sorted by given (first) name, so the article should be sorted under "Yingluck Shinawatra" but readers unfamiliar with her name may be looking for "Shinawatra, Yingluck". Creating Shinawatra, Yingluck as a redirect for categorisation would allow both versions to appear in a category. There's a related discussion at Wikipedia talk:Categorization of people#Regarding January's update. --Paul_012 (talk) 05:24, 3 April 2012 (UTC)

This is a bit like a discussion linked higher up on this page, WT:Categorization/Archive 10#Sortkeys for geographic entities with names in multiple languages. That case was about "alternative name" redirects, and it was decided that categories ought to be on the redirects in addition to, not instead of, the same categories on the target page. However, I do think this is different, as it is a case of using the words with the same spelling but just in a different order. IMHO, these should only appear in a category once.

It is OK to create a redirect in the form you suggest, as this will come up when someone starts typing the name in the search box. However, it should not be categorised.

As a partly-related hint, make sure that the {{DEFAULTSORT}} template has been added above the categories in the article, and uses the first name first. If someone has incorrectly inserted

{{DEFAULTSORT:Shinawatra, Yingluck}},

do not just delete it, as somebody else may come along and re-add it. Instead, change it to

{{DEFAULTSORT:Yingluck Shinawatra}}<!-- Thai names are sorted by first name -->

and hopefully it should be left alone. – Fayenatic L (talk) 17:13, 5 April 2012 (UTC)

Steve Bartman and Steve Bartman incident

Why is the category Sports spectators on both? Reading this policy, I'm almost wondering if it should only be on the redirect, not on the article itself. -- Zanimum (talk) 14:10, 11 May 2012 (UTC)

It should only be on the redirect. Pichpich (talk) 14:53, 11 May 2012 (UTC)

Thanks for also making the change. I was unfamiliar with the policy before recently. -- Zanimum (talk) 15:05, 11 May 2012 (UTC)

Quick question

A redirect such as BABYMETAL should not have a category like "Japanese heavy metal musical groups" right? Xfansd (talk) 17:38, 20 May 2012 (UTC)

Well, depends if Babymetal is a Japanese heavy metal group. If it is, I'd say put it in the category. D O N D E groovily Talk to me 03:25, 21 May 2012 (UTC)

Hard redirect categories

one of multiple new sections posted in one day

Should redirect categories ever be "hard" --in the sense i just now removed Out of Oz from two hard redirect categories? (diffs)

Those two were inherited from a redirect expanded since version 20 June 2012. --P64 (talk) 22:48, 18 December 2012 (UTC)

What to consider when converting a false redirection page?

I have a encountered a redirection page which just redirects to one specific subject, while it should add an explanation and then provide links to pages with the different sub-subjects on Wikipedia. How should I proceed? - 19:11, 21 May 2013 — Preceding unsigned comment added by 99.121.58.187 (talk)

Sounds like you're looking for Wikipedia:Disambiguation. This is the talk page for discussing improvements to the page Wikipedia:Categorizing redirects. --Redrose64 (talk) 09:57, 22 May 2013 (UTC)

Wikipedia talk:Policies and guidelines/Archive 13 #Accepting "WP:Multiple-cross-reference page" as a guideline is a related discussion. BTW, Special:WhatLinksHere/Template talk:R from ambiguous page is a collection of (this and other) links relevant to the problem of ambiguous redirects. Incnis Mrsi (talk) 12:16, 22 May 2013 (UTC)

redirects for school shooting victims have a category

Category:Sandy Hook Elementary School shooting was deleted, however all of these redirects are now found in Category:Deaths by firearm in Connecticut. If there is no significant mention of a person in the article being redirected to, should the redirect for them be in a category? Almost none of those listed in that category have their page, so should they be listed there at all? Dream Focus 03:57, 18 August 2013 (UTC)

I'm inclined to say that all of those redirects should be removed from the category. The Sandy Hook shooting itself is in the category and that's all that's needed. I'll probably remove them from the categories in the next couple days, but I might forget. Ego White Tray (talk) 12:33, 19 August 2013 (UTC)

Redirects without redirect templates

Is there a report listing all redirects without redirect templates? That is, in effect, category: redirect template missing. --P64 (talk) 19:14, 18 December 2012 (UTC)

WT:Database reports would be the proper place to request such a thing. I was thinking of doing so myself, as I'm not aware of such a report existing. --SoledadKabocha (talk) 00:49, 12 September 2013 (UTC)

What is R mh?

While trying to figure out why Category:Pages with templates in the wrong namespace suddenly got so large, I found and removed a call to the nonexistent redirect template {{r mh}}. I seem to remember doing this previously to a different template redirect.

No deletion log entries exist for it. What was its intended meaning, and if it did at one time exist, why was it deleted? --SoledadKabocha (talk) 00:41, 14 January 2014 (UTC)

As you say, there are no entries in the logs for the page, so not only has it not been deleted, it hasn't been moved elsewhere either; hence, it never existed. I suspect a typo, although for what, I couldn't say (in my opinion, these two-letter R templates are way too cryptic). Probably best to ask JPaestpreornJeolhlna (talk · contribs), who created Template:R xw in the first place. --Redrose64 (talk) 11:03, 14 January 2014 (UTC)

Will do. (I thought the absence of deletion logs could have been a glitch or could have preceded the keeping of deletion logs, but the latter couldn't be true because it would likely have been impossible to categorize redirects back then due to the relevant MediaWiki version(s) not parsing anything after the REDIRECT markup.) --SoledadKabocha (talk) 18:04, 14 January 2014 (UTC)

I've found User:JPaestpreornJeolhlna/Index of redirect template shortcuts & abbreviations, and apparently "mh" is an initialism for "missing hyphenation". Based on what I found in that list, I've created Template:R mh, Template:Redirect mh and Template:R missing hyphenation as redirects to Template:R from modification. I've not added any rcat templates to these, because examination of some others that are superficially similar (Template:R mp Template:R ms etc.) reveals a bewildering selection of cryptic R templates. There must be some system to it, but I don't want to pick the wrong ones. --Redrose64 (talk) 20:13, 14 January 2014 (UTC)

I've categorized those shortcuts with the Rcats I've been using for years on Rcat aliases. I've found that JPaest has miscatted several of these sometimes with Rcats and aliases that are only used on mainspace redirects. SoledadKabocha, the reason that Cat:Pages with templates in the wrong namespace has recently grown is due to my conversions of several Rcats to usage of {{Redirect template}}, which handles that categorization. I had recently cleared that cat prior to doing the conversions so the job of clearing the new entries would not seem like such a huge task. Joys! – Paine Ellsworth ^CLIMAX! 14:44, 20 February 2014 (UTC)

"Most redirects should not ..."

(quote) "Most redirects should not be placed in article categories."

Previously I have supposed that few redirects should be in article categories. Now I understand that "most" may simply mean a vast majority, which in turn is unhelpful if it happens that a vast majority are redirects from mis-spellings, plurals, hyphens, etc, and redirects to diacritics, long names, etc.

I wonder whether categories should routinely be retained when an article is replaced by a redirect up one of these hierarchies

• book => series => author
• song => album => artist
• fictional character => whatever (world, book, listof characters, creator)

and no doubt others outside the arts.

• village => county => ... ?
• successive versions of a building under one name ?

Perhaps all categories should be retained by default?

That is, where WP:MERGE instructs "2. Redirect the source page whose content was just merged by replacing everything with the following: ..." it should advise replacing everything except categories.

Only as a secondary point (such as 4. check for double redirects) consider whether any categories should be deleted. --P64 (talk) 20:27, 18 December 2012 (UTC)

I don't have a problem with your suggestions above. The "most" however still applies, since most redirects are for things like punctuation, caps, etc. Ego White Tray (talk) 02:55, 19 December 2012 (UTC)

This " redirects should not be placed in article categories" is utter crap and just another symptom of the way that increasing numbers of WP editors don't have a clue about MediaWiki categorization. Andy Dingley (talk) 23:16, 16 March 2013 (UTC)

2014. Moments ago at WP:MERGE talk I observed that its instruction should be revised, with links to sections 11, 14, and 16 of this talk. See Bad instruction: "replacing everything" with one line. --P64 (talk) 17:39, 20 February 2014 (UTC)

DEFAULTSORT

Perhaps the documentation should here explain when it is desirable for the redirect creator to add DEFAULTSORT as well as some redirect template. And elsewhere --eg, Wikipedia:Template messages/Redirect pages-- those redirect templates likely to be accompanied by DEFAULTSORT may be indicated.

As I understand it, only a few should generally be accompanied by DEFAULTSORT. Two of them are {{redirect to joint biography}} and {{redirect from member}}. R to section and R to list entry (or whatchamacallem) are two others. Because redirects of these kinds are likely or certain to carry Categories --and eventually Metadata in completed templates {{tl|Authority control} and {{Persondata}}.

--P64 (talk) 23:03, 1 July 2013 (UTC)

If I understand correctly, we should recommend adding template {DEFAULTSORT} to the same redirects that are likely to carry category lists.

Offhand I suppose we might recommend that an editor who creates a new or tags a bare redirect, and adds template {DEFAULTSORT}, should also start a category list. --P64 (talk) 21:52, 21 November 2013 (UTC)

Moments ago at WP:MERGE talk I observed that its instruction should be revised, with links to sections 11, 14, and 16 of this talk. See Bad instruction: "replacing everything" with one line. --P64 (talk) 17:39, 20 February 2014 (UTC)

When not to categorize a redirect

See #"Most redirects should not ..." (currently section 11 above) regarding the substantial point. Let me repeat my recommendation:

So the redirect with possibilities retains the categories. -P64

Why doesn't the guideline contain a section of that name? Or do we intend that all redirects in mainspace can potentially be categorized? (I'm not considering other namespaces right now.) --SoledadKabocha (talk) 18:13, 10 November 2013 (UTC)

I would say that nearly all redirects should be in one of the redirect categories, such as {{R from alternate name}}, {{R from misspelling}}, {{R from move}}, etc. Most don't belong in article categories. Ego White Tray (talk) 21:50, 10 November 2013 (UTC)

In my experience Redirects with possibilities should carry category lists, by default the same ones they would carry as articles. FWIW Ego White Tray evidently endorses this one year ago, #"Most redirects should not ...". Let me repeat the recommendation here --a recommendation for redirects with possibilities--

where WP:MERGE instructs "2. Redirect the source page whose content was just merged by replacing everything with the following: ..." it should advise replacing everything except categories.

That is how I have proceeded (no cases of merge or move) with {{R from person}} to spouse biographies and joint biographies, for example David Kherdian (view code). For two older ones set up by previous editors, see Janet Ahlberg (code) and Allan Ahlberg (code). It turns out that I haven't done many fictional character, novel, and book series articles this year.

--P64 (talk) 20:18, 20 November 2013 (UTC)

I just want to chime in that I agree with the above. Apparently we need to word the page differently to better make that point. At the same time, most redirects are things like capitalization and spelling and the like, and those should not be in any article categories. Ego White Tray (talk) 02:54, 21 November 2013 (UTC)

Moments ago at WP:MERGE talk I observed that its instruction should be revised, with links to sections 11, 14, and 16 of this talk. See Bad instruction: "replacing everything" with one line. --P64 (talk) 17:39, 20 February 2014 (UTC)

1.1 Categories just for redirects

quote: There are a series of categories that are used only for redirects. Articles are placed in categories by templates. These categories explain why the redirect exists ...

Many redirect-category templates now display messages that should be useful to editors. (See the preceding section re R from other capitalisation, for example.) As those messages improve, use of the templates to populate the categories becomes more valuable. For instance, Lord of the rings is now in three redirect categories, and no other cats. All three are implemented as hard categories (code) but the first two --if not all three?-- could be done with templates {{R from cap}} and {{unprintworthy}} that would display blurbs as well as populate the categories.
({{R short}} could appropriately be added, too.)

But manual replacement of hard categories by templates is not worthwhile, for that work is easy to automate.

All right? or partly wrong? --P64 (talk) 23:29, 26 February 2014 (UTC)

I'm not entirely sure what you are asking here, but if you mean "Is it OK to automatically replace hardcoded redirect categories with templates that provide the same category?", then as long as this does not change the categorisation (e.g. it doesn't introduce more categories) then I don't see a problem with it, but do make sure you talk to the bot operators to make sure they don't see any problems. Thryduulf (talk) 12:28, 27 February 2014 (UTC)

This is a redirect

Recently, the bugs were fixed that now allow text to be rendered on redirects. For a long time, text was not allowed on redirects, T16323, and the only time any text could be seen was on diff pages and also when a redirect had been disabled to be discussed at RFD. Then last November, a change was made that removed the redirect text from diff pages, T44642. Both of these bugs have been resolved, so it is time to look at improvements of the way text appears on redirects.

A proposal is underway at Wikipedia:Categorizing redirects/Redr to update the How to categorize a redirect section of this project page. Please discuss any alterations to that proposal here before making any changes. The major inclusion is the {{This is a redirect}} template that now can hold up to six rcats along with one each unnamed parameter from any rcat. There is also a new named parameter, "to" that works together with the {{R from alternative language}} template and adds the ISO 639 code of the targeted language.

If I made any errors while adding or deleting material from the section, then please by all means, bring it up here for consideration by all who are interested. If you feel there is a need for more information to be added, then again please mention it here for the same consideration. Thank you for reading and for your important input! Joys! – Paine Ellsworth ^CLIMAX! 20:56, 20 February 2014 (UTC)

It's been about a week since this was proposed, so if there are no objections, I shall include the new material soon. – Paine Ellsworth ^CLIMAX! 10:47, 28 February 2014 (UTC)

Sure thing, WP:SILENCE says it's fine to assume nobody's against it. — Dsimic (talk | contribs) 19:07, 1 March 2014 (UTC)

R from other capitalisation

• Category:Redirects from relatives contains Trigger tha Gambler and Trigger Tha Gambler, both implemented by template {{R from relative}}.

• Category:Redirects from spouses contains Anusha Bhagat and Anusha bhagat both implemented by template {{Redr|wife}}, which is {{R wife}} in effect.

I suppose that the two redirect categories should contain only the first redirect of each pair, which represents the person who is a relative or spouse. The second, underlined redirect of each pair should be in the capitalisation category alone. (These two examples are unique in the relatives and spouses redirect categories, which are now small. I expect to populate them further, by diffusion from R person.)

Thus I think we should make a change, such as what follows in square brackets, in the notice now displayed by Template:R from other capitalisation or {{R cap}}:

quote: From other capitalisation: This is a redirect from a title with another method of capitalisation. It leads to the title in accordance with the Wikipedia naming conventions for capitalisation [or to its target if that page is a redirect], and can help writing, searching, and international language issues.

Alternatively we might shorten the blurb, or reword it, without any specific description of the target page name. As templates {{R from short name}} and {{R from initialism}} do not say that the full name is the target page name (altho {R from initialism} gives that for instance).

Something like this:

From other capitalisation: This is a redirect from a title with a method of capitalisation that does not fit Wikipedia naming conventions for capitalisation.

--P64 (talk) 22:15, 26 February 2014 (UTC)

I'm sorry but I don't understand what you are wanting here. A redirect should never point to another redirect because they don't work (see Wikipedia:Double redirects). Thryduulf (talk) 12:30, 27 February 2014 (UTC)

Yes, no double redirects. But we put redirects from various alternative name forms--say, redirects from other capitalisations, R cap for short--in the substantial "redirects from" categories rather than R cap, when the properly cap'd page is a redirect. Presumably we do this because the R cap blurb includes a commitment that the redirect target is a page with properly cap'd version of its own name. That's counterproductive. Instead put those redirects in R cap but revise that redirect category blurb so that it covers those targets with downstream names rather than properly cap'd versions of their own names, which our no-double-redirect software makes necessary.

R cap, or capitalisation that does not fit Wikipedia naming conventions, is an example. {{R alt}} and {{R from incorrect name}} are two more examples. Our blurbs specify that the target is a page whose name is the proper version of the redirect pagename.

{{R initialism}}, on the other hand, displays a blurb that admits other targets. Expansion of the initialism is a likely target pagename and it is given for illustration. {{R short}} is another one. The source pagename may be a person's full name regardless whether the target pagename is that person's full name.

--P64 (talk) 19:31, 28 February 2014 (UTC)

In the case of {{R from incorrect name}} the correct name (if not the target) can be specified by the unnamed parameter as in {{R from incorrect name|Fairfield}} where "Fairfield" also redirects to the same target, but is not the target itself, e.g., Virginia Western Coal and Iron Railroad. {{R from misspelling}} also has this parameter, e.g., EXIF. Perhaps we can do something similar with {{R caps}}. Let me massage it a bit. – Paine Ellsworth ^CLIMAX! 19:53, 13 March 2014 (UTC)

I have added wording to Template:R from other capitalisation/sandbox that may suffice. Opinions? – Paine Ellsworth ^CLIMAX! 21:14, 13 March 2014 (UTC)

Since there has been no further discussion, the change has been made. Joys! – Paine Ellsworth ^CLIMAX! 09:33, 19 March 2014 (UTC)

Separate sub-category for Greek Letter Organizations (Fraternity/Honor Societies etc)?

It seems to be that the article ΦΒΚ which is a redirect to Phi Beta Kappa doesn't belong in Category:Redirects from initialisms (with say 3rd Congress of the RSDLP) but should be in a subcategory of it. Right now R from initialisms does have one sub-category, Category:Redirects from acronyms. I'm looking for feelings on whether it should be a subcategory and if so, what name should be given to the category/template. My initial idea is Category:Redirects from Greek Letter Organization Letters Naraht (talk) 15:46, 5 February 2014 (UTC)

I actually created (and filled) Category:Redirects from Greek Letter Organization letters (lower case l in last word)Naraht (talk) 15:24, 19 March 2014 (UTC)

Can former names also be short/long names?

In other words, do names that have been changed to a longer or shorter form by the controlling entity qualify for long/short name, or is it required for the long and short forms to be simultaneously in official use? Guy Harris claims the latter (permalink), but I'd like some clarification on whether this is the consensus, since I don't see a previous discussion here. (Clarification: Original version of this post referred erroneously to Guy Macon. This notice placed at 17:35, 12 April 2014 (UTC))

On a related note, which is generally considered the most authoritative description: the text produced by transcluding an Rcat template; the text on the corresponding category page; something else/none of the above? --SoledadKabocha (talk) 07:30, 12 April 2014 (UTC)

Guy Macon may well claim the latter; what Guy Harris claims is that Template:R from long name sounds as if it's intended for cases where the "right" name is the long name, but the most commonly used name is an shortening of that name, without regards to whether the shorter version is "official"; see the examples I cited on my talk page. Guy Harris (talk) 07:51, 12 April 2014 (UTC)

Did anyone follow the link SoledadKabocha posted? He wrote "Guy Macon claims the latter" with a permalink to something Guy Harris wrote. I don't recall ever expressing an opinion on this. --Guy Macon (talk) 08:04, 12 April 2014 (UTC)

That was a mistake. Sorry for not checking more carefully (I did click preview but...) --SoledadKabocha (talk) 08:12, 12 April 2014 (UTC)

No problem. I might as well give you my understanding on this.

Redirects exist so that when someone searches or follows a link they will get to the right place. that is the primary purpose of redirects. All else is secondary and must not interfere with the primary purpose.

The "r from" notation serves a couple of important secondary purposes. One of them is to tell me whether a link is wrong, such as Jumbo Wales. If I find a link to that, I should change it to Jimmy Wales on sight. A link to Jimmy Donal Wales isn't wrong, and thus does not need to be automatically corrected.

When I have questions on which to use, I look here:

Wikipedia:Categorizing redirects

Wikipedia:WikiProject Redirect/Style guide

BTW, as far as I know, "Mac OS X" has never been an Apple trademark. "Mac®" and "OS X®" are registered trademarks of Apple Inc., so you can't call your band "The Mac OS Xs", but they are two trademarks, not one. In theory, Apple could release an "ARM OS X", in which case they would have to go back to calling the OS that runs on a Mac "Mac OS X". In other words, "Mac" has always been a modifier, not part of the name. See https://www.apple.com/legal/intellectual-property/trademark/appletmlist.html --Guy Macon (talk) 08:55, 12 April 2014 (UTC)

OK, so I guess I can't call my band The Tubes either. :-)

Interesting. They give "Mac OS" as a trademark on that page, but not "Mac OS X", and a quick search of [{TESS]] didn't find "Mac OS X" as an Apple trademark. The only "OS X" trademark it found (live or dead) was filed for on November 12, 2008; I don't know whether this means somebody could have come out with "OS X" prior to that, with the only protection against calling your OS "Mac OS X" being the "Mac" part being trademarked by Apple, but that appears to be the case.

But Apple were certainly heavily using "Mac OS X" before Lion (and continued to use it, along with just "OS X", for Lion), and didn't call it "OS X" much (if at all) before Lion, so both are pretty clearly "official" in some sense.

As for correcting links to avoid redirects, whether "OS X" or "Mac OS X" is correct depends on whether it's talking about OS X in general (in which case, if the discussion includes modern versions, "OS X" is probably better) or specific releases (in which case "Mac OS X" is correct for everything from Cheetah to Snow Leopard, "OS X" is correct for Mountain Lion and later, and either one should probably be accepted for Lion). None of "r from short name", "r from long name", "r from former name", and "r from historic name" are, I suspect, inherently wrong and worthy of correction; whether correction is appropriate or not depends on the context.

Wikipedia:Categorizing redirects doesn't seem to address the issue of which "r from" template should be used in which circumstances; neither does Wikipedia:WikiProject Redirect/Style guide. Guy Harris (talk) 09:22, 12 April 2014 (UTC)

I agree with Guy Harris. I should have mentioned that I also rely on the instructions at each "r from" template when deciding which to use. --Guy Macon (talk)

←

Again, I apologize for dragging you into this; thank you for your time and help. I had no intent to canvass or otherwise disrupt; it was genuinely a problem of sloppiness. --SoledadKabocha (talk) 17:35, 12 April 2014 (UTC)

Just to make clear, does former name also invalidate to/from initialism? See for example America Online. --SoledadKabocha (talk) 18:08, 12 April 2014 (UTC)

In the case of AOL, if people generally called it "AOL" before it officially became "AOL", both might be appropriate, but it could also be argued that AOL isn't an initialism any more, in which case "r to initialism" wouldn't be appropriate. Guy Harris (talk) 18:31, 12 April 2014 (UTC)

Breaking section links

I've created lots of rd's, but know little about them. Question: We can use the anchor tag when rd'ing to sections, but in practice that doesn't always happen. Is there a similar benefit to using {{R to section}}? That is, is there a bot that crawls that category periodically to verify that the section names still exist, and flags the rd's that are broken? — kwami (talk) 19:55, 22 April 2014 (UTC)

Hello there! I'd say there are no such bots, as I've fixed at least a dozen of old redirect pages pointing to no longer existing sections. Though, having such a bot would make a lot of sense. — Dsimic (talk | contribs) 04:07, 23 April 2014 (UTC)

See also Wikipedia:Bots/Status. A new bot could be created, or some of the already existing bots which are fixing double redirects could be extended to do that as well. — Dsimic (talk | contribs) 04:18, 23 April 2014 (UTC)

There could be quite a few broken section rd's, more than any one of us could handle. If we ran a bot to flag errors, would you or others here be willing to help fix them? — kwami (talk) 17:50, 23 April 2014 (UTC)

Well, quite frankly I'd rather help by creating a bot that would flag such redirects. :) — Dsimic (talk | contribs) 18:03, 23 April 2014 (UTC)

Yes, that would be more fun! — kwami (talk) 23:30, 23 April 2014 (UTC)

R from symbol

What is the intended use for Template:R from symbol? Currently Template:R from Unicode puts redirects in a subcategory of Category:Redirects from symbols. I assumed all Unicode characters can be considered symbols in a broad sense, but User:Gorobay points out some people would consider letters and numbers to not be symbols in a narrower sense. I also see things already tagged "R from symbol" like Γ ray and Руб which are not symbols, but which could be considered to contain a symbol or be an abbreviation. -- Beland (talk) —Preceding undated comment added 00:09, 28 February 2014 (UTC)

Murder of Kitty Genovese article and categorising redirects

Murder of Kitty Genovese (edit | talk | history | protect | delete | links | watch | logs | views)

I've moved various person-specific categories from the Murder of Kitty Genovese article and placed them on the the "Kitty Genovese" redirect, for example I've moved "1935 births", "1964 deaths" and "American murder victims". An editor has disputed and reverted the change stating they belong on the main "Murder of" article and not on the redirect. We would appreciate it if someone here could explain what is the correct location for the categories. Many thanks.--Shakehandsman (talk) 00:04, 2 June 2014 (UTC)

Please also see as reference the discussion already underway at Talk:Murder of Kitty Genovese. Dwpaul ^Talk 00:12, 2 June 2014 (UTC)

Hmm. Interesting question. The article is not about Kitty Genovese but rather it is about the murder, the victim, the perpetrator, and the reaction and aftermath. It is not about Kitty Genovese and so the 1935 births category doesn't really fit (would we, for example, also include the birth year of the perp?). Not sure whether they should be on the category or nowhere at all. --regentspark (comment) 00:53, 2 June 2014 (UTC)

Well to simply matters maybe we can put the categories of borderline relevance to one side for now and firstly deal with the most relevant categories such as "American murder victims". My view is that an event cannot be a person and therefore the redirect has to be categorised instead.--Shakehandsman (talk) 01:05, 2 June 2014 (UTC)

Yes. That's what I meant above. Person specific categories don't make sense here at all. To elaborate on your example, it would be odd to see both "American murder victims" as well as "American murderers" on the same page unless it were an article on Lee Harvey Oswald. Broader point, the article is not about a person so it shouldn't have person specific categories. --regentspark (comment) 01:16, 2 June 2014 (UTC)

So, given that, what Shakehandsman is asking is whether, for example, it is appropriate instead to place the category "American murder victims" on the redirect page Kitty Genovese -> Murder of Kitty Genovese and the category "American murderers" on redirect page Winston Moseley -> Murder of Kitty Genovese. BMK is suggesting that without exception categories should never be applied to redirect pages, while Shakehandsman contends that is the only reasonable way to connect this article with those very relevant categories. Who is correct? Dwpaul ^Talk 01:25, 2 June 2014 (UTC)

(Later) Reviewing previous discussions, I think the exception described at Redirects whose target title is incompatible with the category would apply to this circumstance (here we are talking about a category incompatible with the target article title but compatible with the redirect title), and that this guidance lends weight to Shakehandsman's position. Dwpaul ^Talk 12:20, 2 June 2014 (UTC)

The question regarding Category:1935 births may be viewed as "who or what was born in 1935 - the crime, or Kitty Genovese?" Obviously, a crime that occurred in 1964 is irrelevant to 1935, so the cat is specific to Kitty Genovese and belongs at Kitty Genovese (the fact that crimes are committed, and not born, is also irrelevant but secondary); the same goes for Category:1964 deaths. Similarly for Category:American murder victims - who or what is the victim, the crime itself, or Kitty Genovese? Again, the cat is specific to Kitty Genovese. All three cats belong on the redir. --Redrose64 (talk) 12:53, 2 June 2014 (UTC)

Many thanks for resolving this matter. In defence of those who were confused about this matter, these policies aren't exactly spelled out very clearly anywhere. While they may be common sense to some, there are a few editors who don't think we categorise redirects. It's also not uncommon to see "murder of" pages containing these inappropriate categories (I think its usually a legacy of someone creating a bio article about the victim and then it being moved to a "murder of" title).--Shakehandsman (talk) 14:35, 2 June 2014 (UTC)

On a similar topic, can editors please confirm whether or not we can categorise the redirect of the perpetrator of such crimes, for example adding Winston Moseley to the "American murders" category. Thanks. — Preceding unsigned comment added by Shakehandsman (talk • contribs) 19:02, 13 June 2014‎ (UTC)

Redirect Winston Moseley has already been categorized using Category:American murderers. Since he was convicted of the crime and is American, I assume this is appropriate in just the same way it is appropriate to categorize a redirect from the victim's name. Dwpaul ^Talk 19:47, 13 June 2014 (UTC)

For the record I fully support the inclusion and above reasoning, I was just attempting to ask the question in a neutral fashion.--Shakehandsman (talk) 21:05, 13 June 2014 (UTC)

Categorizing taxonomic redirects by date of description

Is there any reason not to categorize redirects that are species names by date described? For example Velociraptor osmolskae (redirects to Velociraptor) categorized in Category:Fossil taxa described in 2008. Abyssal (talk) 16:29, 2 September 2014 (UTC)

Can't think of any reason. It's fairly common for plant redirects to have description date categories, and certainly not unheard of for (non-fossil) animals. Plantdrew (talk) 01:36, 8 October 2014 (UTC)

Question of whether songs belong in article cats

User_talk:Richhoncho#Categories_for_redirects  czar ⨹ 19:36, 2 May 2015 (UTC)

↵ Wikipedia talk:WikiProject Albums#Should song redirects be categorized? czar ⨹ 13:08, 3 May 2015 (UTC)

"Shortcuts" of the same length as the target

For example, Wikipedia:ADVOCACY, which redirects to Wikipedia:Advocacy - what category is appropriate for it? It is obviously meant as a shortcut, but it differs only in capitalization, which would be covered by {{R from modification}} (because it is outside mainspace). --SoledadKabocha (talk) 04:45, 8 June 2015 (UTC)

cat|Redirects template needs to be updated

Regarding project page WP:REDCAT, in the "general information note" there is a glitch:

Category:Redirects is a blanked page so the {{Cat|Redirects}} template is broken. The template now points to:

Category:Redirects

The template should point to this page instead:

Category:Wikipedia redirects
Checkingfax (talk) 14:37, 15 September 2015 (UTC)

 Fixed. JohnCD (talk) 15:02, 15 September 2015 (UTC)

Redirects in article categories, workaround

Yesterday I posted WT:RE#Redirects in article categories, workaround, which is relevant here. Now I post this cross-reference at WT:CATP too. --P64 (talk) 17:05, 8 October 2015 (UTC)

Split R from official name, and R from long name

Official names are not always longer, and the policy rationales for tracking the former (WP:OFFICIALNAME and WP:ABOUTSELF, vs. WP:COMMONNAME and MOS:TM debates) are different from the latter (WP:CONCISE and WP:RECOGNIZABLE, vs. other considerations). These should be separate templates and categories. For one thing, the official names cat.'s content should be periodically reviewed for cases of business and other name changes that happened a couple of years ago to see if the WP:RS coverage has caught up and the common name has become the new name, as is often the case after some time passes.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:50, 4 February 2016 (UTC)

R from plural

I just created Wikipedia:List articles as an {{R from plural}} to Wikipedia:List article. I marked it as such, and it says it should only be used in mainspace. I disagree, I am not a fan of cross-namespace redirects but this is not one, I think the tag is somewhat wrong there. It says I should use {{R from modification}}.

I and others over at WP:RFD tend to do a bit of rcatting as a bit of gnomework when we are done, and this just seemed like a bit of gnomework, but I don't see why this should be only applicable in mainspace (article space) rather than in the backroom also. Si Trew (talk) 00:09, 21 September 2015 (UTC)

Same here, regarding Wikipedia:Meetups. --Redrose64 (talk) 09:31, 12 April 2016 (UTC)

I'll take a wild stab and guess that if an rcat is limited in namespace scope, then it means that those who track the redirects that are categorized by that rcat are not interested in tracking that type of redirect in other namespaces.  Stick to sources! Paine  07:32, 13 April 2016 (UTC)

Categories to suggest replacement of redirects with articles

Is it appropriate to categorize a redirect using one of the templates in Category:Expand by language Wikipedia templates? For example, for chanchada, a Brazilian film genre, I created the redirect Chanchada leading to Cinema of Brazil, which mentions it. But I'd like to tag this redirect with {{Expand Portuguese}} to suggest turning it into an article based on the article covering it at Portuguese Wikipedia. I guess I could put it at WP:Articles for creation, but I'm not really begging for an article, I just thought I'd point out the existence of a source for anyone who's interested in tackling it. —Largo Plazo (talk) 08:41, 31 March 2016 (UTC)

I guess you could put the {{Expand Portuguese}} on the redirect's talk page, although of course that's not very visible to the casual reader-cum-editor. Si Trew (talk) 03:57, 12 April 2016 (UTC)

Perhaps the redirect can be mentioned on the target's talk page along with the "Expand Portuguese" template. Also, the redirect can and should be tagged with the {{R with possibilities}} rcat.  Stick to sources! Paine  07:35, 13 April 2016 (UTC)

Rcats discussion

There is a discussion presently at WT:WikiProject Redirect#Rethinking "R to project namespace" & "R to subpage" that involves three namespace rcats, R to project namespace, R to help namespace and R to portal namespace. Unlike five of the eight namespace rcats that are only used outside their namespaces, these three rcats have also been used to sort "same-namespace" redirects, and that quality has been called into question. Your input would help us decide how these three rcats should sort their redirects in the future. Please come give your 2 cents or more.  Stick to sources! Paine  08:56, 21 May 2016 (UTC)

Additional reason

Under the "When to categorize a redirect" section, should "Has potential to become an article of its own" be one of them? Iazyges Consermonor Opus meum 19:11, 13 November 2016 (UTC)

R from alternative anglicisation?

I'm surprised such a category doesn't exist. There is for example the rather specific {{R from diacritics}}, but we don't seem to have a broad one to cover all cases of alternative anglicisations, like alternative transliterations from non-Latin scripts or alternative English renderings of Latin-script names in other languages (for example, for both the Corum and the Chorum variants of Çorum). I don't know of any existing rcat that could possibly cover this ground and I think this is a ground that needs covering. Any thoughts? — Preceding unsigned comment added by Uanfala (talk • contribs) 07:37, 9 September 2016 (UTC)

To editor Uanfala: so sorry, I just saw this. Rcats and their maintenance categories have in the past been created whenever there was a need to fill, for example, {{R from alternative transliteration}}, {{R from Wade–Giles romanization}} and their categories were created to fill needs similar to what you suggest. Do you think there is a need for another rcat, or more than one?  Paine Ellsworth  ^u/c 00:59, 2 December 2016 (UTC)

I wasn't aware of {{R from alternative transliteration}} when I posted this question back in September. I think it's generally useful if a redirect from an alternative transliteration contains information about the transliteration scheme used. I don't know this fits in the grand scheme of things, as I don't know what the big picture is in redirect categorisation. If something like this is adopted, then I don't think it's sensible to have a separate template for each type of transliteration used (there quite a lot of them out there), and it's probably best to handle that with a parameter: for example {{R from alternative transliteration|IAST}} to indicate that the scheme used is IAST. – Uanfala (talk) 13:29, 3 December 2016 (UTC)

categorizing redirects as though they were articles

See also: fr:Discussion Projet:Catégories § Catégorisation d'une redirection

I recently had an edit reverted because another user suggested that we should not be categorizing redirects as though they were actual articles. He pointed me here.

I'm not sure I interpret that the same way he does. Is that the case? The example is The Hell or High Water EP which used to be part of the category Category:2010 EPs. (It was actually there when I got there, I just added DEFAULTSORT)

That category contains 23 redirects. If this is the policy, is someone going to clean up the probable 100s of thousands of cases like this? Fuddle (talk) 15:04, 13 September 2017 (UTC)

Categorising redirects into article categories is ideally done with measure, but it is done nevertheless, as the bulk of the guidelines on this project page clearly testify. Maybe the editor who pointed you here could explain what they meant? – Uanfala 15:15, 13 September 2017 (UTC)

I would contact him again, but he told me to "stay off my talk page" Fuddle (talk) 15:28, 13 September 2017 (UTC)

Judging by this post, I assume that these are the discussions concerned. Seems somewhat one-sided. --Redrose64 🌹 (talk) 20:48, 13 September 2017 (UTC)

To editors Fuddle, Walter Görlitz, Uanfala and Redrose64: this editing guideline, which editor Görlitz left on editor Fuddle's talk page, is very clear about redirect categorization in article categories. Whether or not any editor disagrees with this consensus, the sorting of redirects to article categories is and has been the community consensus for many years now. Anyone who reverts a valid edit that sorts a redirect to an article category in accord with this project page is going up against the consensus of the community. Rather than indiscriminately reverting such edits, the reverting editor should bring the discussion to this talk page and try to get the consensus changed. To be up front about how I would !vote, I personally see no reason nor logic in keeping redirects out of article categories when it is appropriate to sort them in that manner.  Paine Ellsworth  ^put'r there  20:23, 7 October 2017 (UTC)

Thanks for that comment. It's an incorrect consensus then. If I, as a reader, come to a cat page and see a link to subject X and I click through to it, I expect to see an article on X. If am redirected to an article about the creator of X or some other topic that includes X, but never describes X, I will be annoyed. Not trying to change the consensus, but I'm complaining that it's wrong and will result in people thinking we're ignorant and wasting their time. I'll honour the consensus but I don't like it. Walter Görlitz (talk) 21:09, 7 October 2017 (UTC)

It's a pleasure, Walter Görlitz! We'll have to "agree to disagree", since I think of this as a long-standing and correct consensus. And perhaps you missed the tech note near the bottom of this project page? If you, as a reader, come to a cat page and see a link to subject X and that link is in italics, then you know it's a redirect before you even click on it. So I really don't see a problem. Sorting some redirects to article categories can be useful and helpful to readers. That is why the consensus is in place, and that is why it's correct.  Paine Ellsworth  ^put'r there  19:14, 8 October 2017 (UTC)

I see no difference between your scenario, in which you are following a link to X from a category page, and a scenario where you are led to subject X by any other route. What's annoying you is that the redirect is misbegotten. The fact of having been categorized by someone has nothing to do with it. If the article about the creator of X were to include the information "In 2014 she created X", then all would be clear, and arriving at X through a category would cause no more befuddlement than arriving at X through any other path. And then a user interested in getting information about all the topics in category C about which information exists on Wikipedia will have access to it. Whether the information available here for each of those topics is in an article devoted to that topic or in an article devoted to a related topic will be immaterial. Largoplazo (talk) 19:50, 8 October 2017 (UTC)

In situations like this I usually mention Honey Lantree. Unless further reliable sources can be found, she's notable for just one thing - being the drummer with The Honeycombs. Hence she has a redirect to the band page, but no separate article of her own. On the redirect there are four categories: Category:Living people (mandatory for non-dead people); Category:1943 births (required for biogs); Category:British female drummers (see below); plus hidden cat Category:Redirects from members, this being due to {{R from member}}. The "controversial" one here would be Category:British female drummers - this is a "Fooian fooers" cat, but can you think of anything more appropriate? If this category were on the article The Honeycombs, it would be doubly inappropriate: The Honeycombs were not all female, and they were not all drummers. But omitting this cat from the redirect would mean that the likes of Karen Carpenter, Maureen Tucker or Meg White were deserving of categorisation when Honey Lantree was somehow not. --Redrose64 🌹 (talk) 18:52, 9 October 2017 (UTC)

I've never in 12 years and more here encountered the idea that redirs should not be categorized like articles when they are a {{R from subtopic}} or the like and could theoretically be their own article (i.e. we don't so categorize things that are just alternative names for a topic, only distinct things that happen to be covered at the same article, like band members, albums, side projects, songs, etc., all redirecting to a band article). So, yes, Lantree should have that category – if it's to be retained (see new thread I'm starting next).  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  07:00, 1 January 2018 (UTC)

Request for comments on MoS shortcut redirect categorization

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Should MoS shortcut redirects be sorted to certain specific maintenance categories?  Paine Ellsworth  ^put'r there  15:59, 14 December 2017 (UTC)

Another editor, SMcCandlish, and I would appreciate more eyes on this issue. This question has been ongoing for some time and was brought to this RfC by the following two instances of opposing opinions:

1. Please see the edit history of this MoS shortcut redirect, where contention can be seen in regard to whether or not it should be sorted to Category:Redirects to subpages, Category:Redirects to Wikipedia project pages and Category:Unprintworthy redirects by using their associated rcats.
2. See also our discussion on my talk page, which I bring here as extended content in the following:

Moved from User talk:Paine Ellsworth § rcat

Can you please avoid adding pointless rcats to shortcuts like "MOS:WHATEVER"? From just one example: MoS pages are not subpages, they're stand-alone guidelines that happen to have "/" in their names (with a handful of exceptions, like actual supplementary subpages of WP:Manual of Style/Accessibility). They don't need to be categorized as redirs to project space. "WP:FOO" shortcuts are already in project space, and "MOS:" one all go there; it's implicit in their purpose, so tagging all several hundred of them is a waste of time and just bloats the rcat block. If there's some really important maint. reason to tag the "MOS:" ones with this, I could stop objecting to it, but I've been removing this rcat on sight in "MOS:" shortcuts for years, and no one has ever objected or reverted. They also don't need to be rcat'ed as unprintworthy, since they're not used in mainspace. (That should be used on things like hatnote templates that cross-reference different articles because our content is meant to be reusable as-is on a per-article basis.) As someone who does a lot of shortcut maintenance, it's a hassle to have a thick pile of rcats on these things that interfere with quickly assessing exactly what they are and why they exist. The only ones we really need are shortcut (for building lists of shortcuts), and either section or anchor as applicable (for maint work on anchors that are not section links, e.g. replacing markup like <span id="something"></span> and <span id="something" /> with {{anchor|something}}).  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  00:44, 3 December 2017 (UTC) Not sure what gave you the idea that categorizing redirect shortcuts with appropriate rcats is "pointless". MOS shortcuts are in mainspace and therefore should definitely be sorted as "unprintworthy" so they don't appear in any "printable" versions of Wikipedia, such as any CD/DVD versions. What in the world makes you think that sorting those shortcuts to the Unprintworthy redirects category is not the right thing to do???  Paine Ellsworth  put'r there  01:01, 3 December 2017 (UTC) Already said: they are not used in the text of articles, so they'll never appear and need to be suppressed in articles.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  10:25, 3 December 2017 (UTC) As to using the rcat to project space, do you expect that editors are mind readers? How do you expect the MOS shortcuts, which are vivid WP:CNRs, to be detected? Category:Redirects to project space is most assuredly an appropriate category for these as much as it is for other CNRs.  Paine Ellsworth  put'r there  01:01, 3 December 2017 (UTC) No editor who does not already know that "MOS:" goes to MoS pages in project space is competent yet to be doing any kind of maintenance, with redirects or otherwise. There is no need to "detect" MOS shortcuts since they all are of the same form, "MOS:" followed by something; and nothing else is of that form. If some day there's something notable in the real world named something like "MOS:FOO" then will we ever need to distinguish "MOS:" CNRs from something that isn't one. Unless that day comes, the "MOS:" shortcuts are auto-"detected", simply be being as they are.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  10:25, 3 December 2017 (UTC) As for subpages, you haven't made a very strong case there, either, SMcCandlish. Just what exactly makes, say, WP:Manual of Style/Capital letters any different from WP:Manual of Style/Accessibility? They are both subpages of the MOS, and I see no difference. If as you say, "Capital letters" is stand-alone, then why is it on a subpage of the MOS instead of at WP:Capital letters? Both pages are about style, so both are subpages of the Manual of Style. It seems to me that you are wrong on all counts and should be soundly trouted for removing redirects from appropriate categories. Happy Holidays to you!  Paine Ellsworth  put'r there  07:28, 3 December 2017 (UTC) The only "case" that needs to be "made" is that they have guideline tags on them. They are not subpages, they are guidelines that happen to have "/" in their names; please don't make me repeat myself. Do you think that the redirect WP:AC/DS is a subpage of the redirect WP:AC? It is not. It just happens to have "/" in its name. We chose to name the MoS pages this way rather than in the pattern of the NC pages (WP:Naming conventions (people), etc.) because parenthetic disambiguation was felt to be awkward or something. They could actually be moved to things like WP:Manual of Style (dates and numbers) and so on, and these do exist as redirects. The actual subpages (e.g. Wikipedia:Manual of Style/Accessibility/CSS colors for text on white, Wikipedia:Manual of Style/Glossaries/DD bug test cases, Wikipedia:Manual of Style/Accessibility/Data tables tutorial, maybe a few others) are not guidelines and are not tagged as guidelines (I actually did find one mistakenly tagged that way and fixed it; it's a {{Wikipedia how-to}}). I think you're confusing "subpage" as meaning "anything faintly like a hierarchical relationship", or "anything that contains a slash character", and it doesn't mean either of those things. A subpage is a dependent page such that were the parent page deleted the subpage would also be deleted, because it serves no purpose on its own. We could in fact delete the entire WP:Manual of Style page and it would have no effect on the other MoS guidelines, since the main MoS page is simply a summary of their most important and commonly needed points. PS: MOSCAPS isn't at WP:Capital letters because we agreed to group the style stuff under "Manual of Style" as a heading, exactly as all the NC pages start with "Naming conventions", and are not at names like "WP:People" for WP:Naming conventions (people). The super-short names are too ambiguous to make it clear what their scope is. We do in fact have multiple pages about capital letters and about people and about most things for which we have MoS or NC pages (e.g. WP:Naming conventions (capitalization) and WP:Manual of Style/Biographies, respectively; these could be more consistently named, but no one is losing sleep over it).  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  10:25, 3 December 2017 (UTC) Thank you! because I'm beginning to understand your reasoning as it applies to the, shall I call them "pseudo"subpages? which just means there is no rcat for "redirects to pseudosubpages". That is one of three issues to which I'm warming up. So how do you suggest we resolve the other two issues? (unprintworthiness and CNR tracking of MOS shortcut redirects)?  Paine Ellsworth  put'r there  01:01, 4 December 2017 (UTC) Congratulations, SMcCandlish, for your decision to run! Just wanted you to know that these issues are not something that can't wait, so keep your "eyes on the prize" and may good fortune be your ally!  Paine Ellsworth  put'r there  14:52, 6 December 2017 (UTC) I guess the question is what utility is provided, what purpose is served, by {{R to project namespace}} and {{R unprintworthy}} on those particular shortcuts? The first is for things like Create an article – stuff that we expect users might want to type into the URL bar as a guess, without realizing WP has namespaces. Some other examples are things even experienced users might try, like List of hoaxes on Wikipedia, which is a topic that could in theory be notable and have an encyclopedia article but which isn't and doesn't (insufficient in-depth coverage in independent reliable sources), but which we do have an internal page about. Shortcuts like "MOS:CAPS" aren't either kind of case. And by virtue of what they are, we already know they're project-space redirs anyway. If some day there's something called "Mouse-Optional Synergistics: An Operating System", and its conventional acronym is "MOS:OS", then and probably only then would we have a need for that rcat on "MOS:FOO" shortcuts, to distinguish from real-world things that start with "MOS:". The latter rcat is for redirs that we want to replace in displayed article text with the actual name of the article because they're "deficient" names in some way, in an encyclopedic sense; this is a pure maintenance category, for gnomes to use in fixing wording to make good sense in a printed article. There is no case in which something like "MOS:CAPS" or "Wikipedia:Manual of Style/Capital letters" should appear in an actual article's text.* And Category:Redirects from shortcuts is already a subcat of Category:Unprintworthy redirects, so using {{R unprintworthy}} when {{R from shortcut}} is already used is redundant. [* In theory, there could be one someday: INDY RS could eventually write a whole bunch of stuff about WP's MoS and make it real-world notable. That's a bridge to cross if we come to it.] So, it's not that these redir categorizations are "dead wrong" or whatever, it's just unnecessary, and both a waste of your editorial time to add these rcats on these shortcuts (and perhaps of other editors' time, in maintaining them later), as well as an annoyance to the actual maintainers of the MOS shortcuts (which may not even be plural – it may just be me!) by doubling the rcats per shortcut and slowing down the correction of things like an {{R to anchor}} needing to be changed to {{R to section}} or vice versa, and sometimes a concurrent update to the exact in-page target; aside from a missing {{R from shortcut}} on a few of them, that's all the maint they need.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  00:48, 7 December 2017 (UTC) To editor SMcCandlish: I've thought a lot about my response to your question about utility, and I hope that you will approve and agree with me. In terms of the printability rcat, it's true that both {{R from shortcut}} and {{R to project page}} automatically sort mainspace redirects to the Unprintworthy redirects category. For many years I have practiced placing the {{R unprintworthy}} rcat on those redirects even though it is not needed functionally to sort them to the unprintworthy category. The reason I've always done this is for those editors, mostly inexperienced, who haven't set their "See hidden categories" preference. By applying the rcat to those redirects, editors are able to see that the redirects are sorted as unprintworty even if they can't see the categories at the bottom of the redirect page. It is also good in my opinion for editors who can see the categories at the bottom, because the rcat also functions as an information source for editors. I've always done this with printworthy redirects as well, for example, some rcats such as {{R with possibilities}} automatically populate the Printworthy redirects category, and yet I still tag those redirects with {{R printworthy}} to accommodate inexperienced editors, which I think helps them gain experience and knowledge about the "low-end" Wikipedia need to categorize redirects. I hope you agree that this is an important reason to use the printability rcats even when they are not needed to actually sort redirects to their categories, and I see no reason to start making exceptions for certain types of shortcut redirects. The {{R to project page}} rcat is in a similar boat. There is no reason to make an exception for the MOS shortcut redirects. That rcat sorts to three categories, one for project-page redirects, one for cross-namespace redirects, and one for printability of mainspace redirects. Those are all tracking categories and are large enough to warrant bot tracking. Making an exception for the MOS shortcut redirects, which are clearly CNRs, would in effect defeat the purpose of the tracking that has been set up for many years. I find that discussing this with you has been informative, and I certainly mean no disrespect when I say that either one of us could be wrong. If you find that you still cannot agree with me about the utility of using the project and printability rcats on the MOS shortcut redirects, then we should probably seek the opinions of other editors on the matter. Hope your holidays continue to be happy and healthy!  Paine Ellsworth  put'r there  01:39, 12 December 2017 (UTC) Sure, I always prefer a discussion over a squabble. :-) I'm not sure I follow the first of these points. If the editor is too new to know about "See hidden categories" why would they be experienced enough to know about unprintworthy redirect sorting? I'm not inclined to go editwar about these rcats, but would suggest opening a discussion at Wikipedia talk:Categorizing redirects, with a pointer to it from Wikipedia talk:Categorization, Wikipedia talk:Overcategorization, Wikipedia talk:Redirect, and Wikipedia talk:WikiProject Redirect to get extra eyes and brains. We do actually permit some forms of redundant categorization, but they're limited; whether to treat this kind of maint categorization as diffusing or non-diffusing is probably significant enough it shouldn't be just between you and me. Heh. I can see that there is potential utility in doing it your way, but is the utility worth the hassle (i.e. the anti-utility for others)? From my personal perspective it's not, since I do most of the maint. relating the pseudo-namespace in question; I don't think any of the kinda-new editors you're seeking to help out here are involved in any way with editing "MOS:" shortcuts, or more than very rarely even the "WP:" and "WT:" ones for that matter. Given the different sorts of unprintworthy redirs and the large total number of them, there's a good chance that maintainers in general will object to having them in the main category for them as well diffused to one or more of its subcats, instead of treating the main one as a container cat. I'll just concede on tagging the "MOS:" ones with {{R to project namespace}} (and have already started checking; have done all the ones at Special:PrefixIndex/MOS: that precede "A" in the alpha-order list already, doing the As next). While it seemed superfluous to me, you're correct that it creates a gap in "total redirs to project-space" and "total CNRs" tracking; I was arguing from an editorial not bot utility perspective (bots may not be coded to "know" what editors actually know about page names starting with "MOS:"). However, using that Rcat actually strengthens (at least marginally) the notion that {{R unprintworthy}} would be redundant. Anyway, {{R to project namespace}} should not be used on "WP:" or "WT:" redirs, since they're not CNRs; those have been made into actual aliases of "Wikipedia:" and "Wikipedia talk:", respectively. I'm sure you know that, but I do keep finding that Rcat on them, and it's just wrong, regardless who's putting them there.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  04:26, 12 December 2017 (UTC) To editor SMcCandlish: to repeat... rcats do more than just sort redirects to categories. They provide information in their texts about the categorization, and again, this is a learning tool whether or not editors can see hidden categories. So it is just as important, for information and tracking purposes, to tag WP (not WT) shortcuts with the projectspace rcat so they will be tracked in that rcat's non-CNR Category:Redirects to Wikipedia project pages. That is specifically for redirects that are in projectspace that target projectspace pages, a long-standing tracking process. And you might be surprised that there are editors who want to help, but who thus far lack the information they need to help. That's why rcats are designed as learning tools in addition to their more functional sorting abilities. Thank you beyond words for your help in this!  Paine Ellsworth  put'r there  15:58, 13 December 2017 (UTC) I don't strenuously disagree with that, I just don't think it's sufficient in this case (with regard to the point I didn't concede on). I could be wrong, which is why I suggest an RfC or something. There are a lot of people way more particular than me and probably you about categorization (both against and for the position I've taken).  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  16:06, 13 December 2017 (UTC) Agreed, and I shall prepare an RfC in the manner you suggested above. I know several editors who have been involved with redirect categorization, and while I have no idea how they would !vote, I shall ping them to make sure they're aware of the discussion. L8RG8R –  Paine Ellsworth  put'r there  16:17, 13 December 2017 (UTC)

While our two opinions seem to have come to some level of agreement on my talk page, we both believe that it would be beneficial to Wikipedia if these issues could receive the opinions of other editors. Thank you in advance for your decision.  Paine Ellsworth  ^put'r there  16:07, 14 December 2017 (UTC)

A little note to say that, while I support the notion of full usage of these rcats and cats in their present form, I will be happy to create/implement any changes that result from this discussion.  Paine  20:59, 14 December 2017 (UTC)

• Yes. As seen on my talk page, I did warm to the exclusion of the {{R to subpage}} tag; however, I would still appreciate more opinions on whether or not to call Wikipedia:Manual of Style/Capital letters#Acronyms, which is the target page of the MOS:CAPSACRS shortcut redirect, a "subpage". And I continue to consider the tracking and information functions of the other two tags, {{R to project page}} and {{R unprintworthy}}, as appropriate for all MoS shortcut redirects. I see no need to make exceptions for one type of shortcut redirect.  Paine Ellsworth  ^put'r there  16:07, 14 December 2017 (UTC)
• Comment. By technical definition they are certainly subpages. Whether they are functionally subpages may be another matter, but there is no question that they are subpages. Each of them has a breadcrumb link under the title that links to the "main" page for that subpage. While any benefits may be marginal, I don't see any harm in categorizing them as such. Similarly, it seems Category:Redirects to Wikipedia project pages is certainly an appropriate categorization for these. It's kind of irrelevant whether editors understand what the MOS prefix does when the point of the category is to collect these redirects into a single group (and anyone interested can watch the category to spot changes to such redirects). If anything, there might be a case for sub-categorization of MOS redirects. I don't really have much use for or opinion about Category:Unprintworthy redirects, so I'm OK either way with that one. older ≠ wiser 17:21, 14 December 2017 (UTC)
• (edit conflict) Include all. I was invited here by a notice on my talkpage. I've read the edit history link and the collapsed discussion above, and I find myself in complete agreement with Paine Ellsworth - every redirect that is a shortcut should be tagged as being such, likewise every redirect to project space, cross-namespace redirect, to a subpage, etc, should be tagged with all the categories that apply. The reason these exist is so that bots, etc. can include or exclude what they do/don't want with ease without needing to know exceptions. There are mirrors that only take mainspace content, and they do not want titles that redirect out of mainspace - there is no way without tagging it as such for a bot to distinguish between redirects like MOS:/ (→ Wikipedia:Manual of Style#Slashes) and [[http://]] (→ Hypertext Transfer Protocol).
  Regarding the subpage issue, Wikipedia:Manual of Style/Capital letters seems to me to be functionally and structurally indistinguishable from a page like Wikipedia:WikiProject Biography/Military or Wikipedia:In the news/Candidates, which are unarguably subpages. The guideline regarding image captions is located at Wikipedia:Manual of Style/Captions, a subpage of the Manual of Style, if it wasn't a subpage it would be located at Wikipedia:Captions, which redirects to the subpage. Thryduulf (talk) 17:35, 14 December 2017 (UTC)
• Can we not just have something like a Category:MOS shortcuts, which itself includes all categorizations relevant to these links? bd2412 T 17:52, 14 December 2017 (UTC)
• Make a MOS-shortcut rcat as suggested by bd2412 which can pass the other cats I guess. The subpage matter I'm ambivalent about -- functionally, in Mediawiki software, yes the individual MOS guidelines are subpages. However there are many usages for subpages, some more dependent on their parent, some less (like MOS). What is the net benefit of the "redirect to subpage" category anyways? However MOS redirects should definitely be marked as unprintworthy because MOS: is not an actual namespace shortcut (as opposed to WP:, for example) and thus Mediawiki considers the MOS shortcuts to be in mainspace. Without an unprintworthiness rcat, they'd be included if anyone printed "all Wikipedia articles starting with M", for instance. The "R to project page" rcat shouldn't even be a discussion, it's a mainspace title redirecting to projectspace, plain and simple. Ben · Salvidrim! ✉ 18:28, 14 December 2017 (UTC)

  I'd be fine with Train2104's proposal for a PNR rcat instead of a MOS-specific one. This PNR cat should include unprintworthiness and R-to-projectspace. Ben · Salvidrim! ✉ 19:05, 14 December 2017 (UTC)

• Make a category for mainspace shortcuts, to include these MOS shortcuts as well as "CAT:" and "T:" shortcuts. There is value in independently keeping track of these, since the software considers them as articles. They should also have the R to projectspace tag, but I'm not too sure of the utility of R to subpage. The various guidelines are subpages of MOS, but they aren't "dependent" on it per se, they usually stand alone. – Train2104 (t • c)
• Comment. Let me ask editors to keep in mind that rcats serve in two main areas, 1) they categorize redirects, and 2), they provide information about their categorization to editors. In the first area, some rcats sort redirects to more than one category, for example, {{R from shortcut}} populates Category:Redirects from shortcuts and (when the redirect is in mainspace) Category:Unprintworthy redirects by default. So the issue in this case is whether or not the {{R unprintworthy}} rcat should be used to tag MoS shortcuts, since both the R from shortcut and R to project page rcats automatically sort mainspace redirects to the Unprintworthy redirects category. I maintain that R unprintworthy should still be used, and this brings us to the second area of service, which is to inform editors with details about why a redirect is sorted to a particular category. This doesn't just help inexperienced editors who want to learn how to help. Even though I have been working in redirect categorization for many years, I still sometimes find myself using the {{tl}} template to read the rcat text first to make me certain that I tag a redirect with the correct rcat. So even though the printworthiness rcat is not necessary in these cases to actually sort the MoS shortcuts to the unprintworthy category, tagging them with R unprintworthy provides helpful information for editors.  Paine Ellsworth  ^put'r there  20:10, 14 December 2017 (UTC)
• Comment – (edit conflict) – does {{R from shortcut}} cover it? Ping me back. Having fun! Cheers! {{u|Checkingfax}} {Talk} 20:13, 14 December 2017 (UTC)

  To editor Checkingfax: the R from shortcut rcat sorts only to Categories: Redirects from shortcuts and Unprintworthy redirects. It does not sort to the project page and subpage categories. Are we having fun yet?  Paine Ellsworth  ^put'r there  20:23, 14 December 2017 (UTC)

  Hi, Paine Ellsworth. I have been involved in UNIX directory structure web hosting since 1996 and when a URL has a forward-slash in it, that tells me that anything to the right of it is a sub-directory (or file), and so on. I do not see anything pseudo about it. Is that what McCandlish is getting at? Having fun! Cheers! {{u|Checkingfax}} {Talk} 20:37, 14 December 2017 (UTC)

  To editor Checkingfax: if I understand the premise, even though the target of the shortcut is technically a subpage, the shortcut redirect should not be sorted to the subpage category because the target is a "stand-alone" project page.  Paine Ellsworth  ^put'r there  20:43, 14 December 2017 (UTC)

  I don't think it is obvious that these project pages are not subpages, even if some might consider them to be standalone. They are named the way that the are to group them together and that was deliberately done to bring some degree of order to the chaos that preceded them. older ≠ wiser 21:13, 14 December 2017 (UTC)

  In this case I'm just not sure. It makes me think of a time long ago when mainspace pages had functional subpages. We moved past that, and yet we hang on to a "need" to continue to use subpages in projectspace. And yet, there is definite utility for subpages in templatespace for such as /doc & /sandbox pages, as well as other "sub-template" pages. Until now, except for titles that use a solidus supported by reliable sources, I have treated all usages of the solidus as subpages of the "next higher level" of page. I could be wrong, which is why I began this Rfc.  Paine Ellsworth  ^put'r there  21:36, 14 December 2017 (UTC)

  To editor Checkingfax: You might want to take a look here: Wikipedia:Articles with slashes in title. Ꞷumbolo 20:45, 14 December 2017 (UTC)

  Hi, Wumbolo. Those for the most part are not sub-sets. They are pseudo-hyphens. For instance, DC is not a sub-set of AC. Having fun! Cheers! {{u|Checkingfax}} {Talk} 22:41, 14 December 2017 (UTC)

  Hmm? Sure it is. Well, you'd normally say "fragment" rather than "subset", but dependent choice is indeed a fragment of the axiom of choice. --Trovatore (talk) 00:59, 15 December 2017 (UTC)

• This should have been more specific. The question may be too vague for us to get a clear consensus answer. To summarize my answers template-by-template:
  • Yes for now on {{R from shortcut}}
  • Yes for now on {{R to project namespace}} a.k.a. {{R to project page}} (Paine convinced me some maint. bots need this).
  • Better yet, create a {{R from MOS shortcut}} and {{R from category shortcut}} (a.k.a. {{R from CAT shortcut}}), while we already have {{R from template shortcut}} (which should have a {{R from T shortcut}} alias). Code these to detect originating namespace (at least for {{R from template shortcut}}, which has multiple uses), and categorize as needed. E.g. for "MOS:" ones, {{R from MOS shortcut}} should put them in Category:Redirects to project space and in a Category:Redirects from mainspace shortcuts that is a subcat of both Category:Redirects from shortcuts and Category:Cross-namespace redirects.
  • Yes on either {{R to section}} or {{R to anchor}} if one of these is applicable in a particular case.
  • No on {{R to subpage}} – MoS guidelines are not subpages in the WP:Subpages sense (neither editors nor readers care what the MediaWiki engine thinks they are). They're stand-alone guidelines that happen to have "/" in their names. You could delete the entire WP:Manual of Style main page, and all the MoS pages would continue as guidelines, in perfect working order. That page is just a summary of their key points. They have names like WP:Manual of Style/Capital letters instead of WP:Manual of Style (capital letters) simply due to historical accident.
  • No on {{R unprintworthy}}, since {{R from shortcut}} already adds Category:Unprintworthy redirects, and Category:Redirects from shortcuts is also already a subcat of Category:Unprintworthy redirects, and so is Category:Redirects to project space‎. Adding {{R unprintworthy}} would be triply [BrEng: trebly] redundant.
  • PS: Several subcats of Category:Cross-namespace redirects need to be renamed for consistency, to use "namespace" not "space".

   — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  22:06, 14 December 2017 (UTC)

  Just to be clear about usage of {{R unprintworthy}}: you are partially correct, because the printability rcats are often used in this "redundant" way. There are several rcats that, in addition to their main categories, they also sort to Category:Unprintworthy redirects, so for the first purpose of all rcats, which is to sort to maintenance categories, this is "redundant" usage. What about the second purpose of all rcats? The second purpose of all rcats is to provide to editors information about the categorizations, so there is absolutely no redundancy involved in this respect when the printability rcats are used to tag redirects. I do this all this time, for example with Bua (disambiguation) that redirects to Bua (a no-primary-topic disambiguation page). The {{R to disambiguation page}} rcat sorts to Category:Unprintworthy redirects by default, but that is no reason to exclude the {{R unprintworthy}} rcat and its textual information.  Paine Ellsworth  ^put'r there  19:48, 17 December 2017 (UTC)

  Please provide a practical use case for having {{R unprintworthy}}, despite 3× redundancy, on all these shortcuts. Like, give us a workflow that actually needs this. Then explain what actually good it's doing for the project. Redirects exist to get us where we need to get to. We should not spend one second categorizing them internally for maintenance purposes unless that maintenance is genuinely productive, will actually happen, and is best served by doing it that exact way.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  10:58, 30 December 2017 (UTC)

  I have already provided a "practical use case for having {{R unprintworthy}}", so I'm not exactly certain of what you're asking for here, SMcCandlish. If you want me to justify the categorization itself, the printability rcats were created, were used and are still used to help decide which article-space redirects do or do not belong in printed versions of Wikipedia, the encyclopedia. We agree in regard to categorizing redirects internally for maintenance purposes only when that maintenance is genuinely productive, will actually happan, and is best served by doing it that exact way. So your challenge there goes without saying, and the printability rcats certainly meet that challenge, as previously described. And there is no true redundancy here as regards the categorization. True redundancy would be indicated by a redirect actually being entered into a category more than once, which never happens. I could tag a redirect with {{R printworthy}} ten times, and that redirect would only appear once – one time only – in Category:Printworthy redirects. So there is no true redundancy in adding the printworthy rcat to, say, a redirect that has also been tagged with {{R with possibilities}}, which automatically sorts to the Printworthy redirects category. The redirect will only appear in the Printworthy redirects category one time, hence no redundancy. Now we once again come to how important it is that the information provided by each rcat be allowed to appear on redirects. I consider and have always considered that the informative text found on rcats is just as important, if not more important, than the category sorts made by the rcats. So I consider it to be imperative that all category sorts be accompanied by the appropriate rcats, in this case the {{R unprintworthy}} rcat, in order to convey information about the category sorts to editors. Less is not more when it comes to informing editors with these rcats. You must know where I'm coming from, because you've been here long enough to know just how difficult it has been over the years to understand the redirect category system simply because editors back then just did things without explaining what they did. You and I had to dig and dig to find out why and how other editors did things. So we now provide editors with information about why and how things are done for the express reason that it won't be as hard for them as it was for us!  Paine Ellsworth  ^put'r there  14:54, 31 December 2017 (UTC)

• Yes – If a page fits into a category, it should be in that category (or a subcategory). Whether an entire category is needed or is necessary is another discussion.
  • MoS pages are subpages of the main Wikipedia:Manual of Style. There is a lot of information on that main page, with more specific information spun-off into subpages. If there was no information on the main page and the whole MoS was broken in subpages, then you would have a point that the subpages are all standalone guidelines, but this is not the case. The situation doesn't seem any different to any page with subpages.
  • The redirect is a redirect to a project page. It's not obvious to everyone what the purpose of MOS redirects are. Categorising cross-namespace redirects is important for technical reasons.
  • Printworthy and unprintworthy redirects are for inclusion/exclusion in a possible print edition of Wikipedia, and we should assume, just in case, that non-mainspace pages could be included. Redirects designed for speed rather than related topics or search queries are unprintworthy (because they're only useful for typing), so this redirect is unprintworthy. However it has been pointed out above that another template already adds unprintworthy, meaning the specific template for unprintworthy is unnecessary.
  • I agree with making a specific template for MOS redirects that would categorise (or subcategorise) them as redirects to project space, shortcuts and unprintworthy. (Not all MOS redirects go to subpages or sections/anchors.)

  M.Clay1 (talk) 23:58, 14 December 2017 (UTC)

  Your first point is incorrect, for reasons I've already explained. They are independent guidelines, or they could not have {{Guideline}} on them. As a matter of WP:CONLEVEL policy, they're interpretationally subordinate to the main MoS page (i.e., what it says overrides them if there's ever a WP:POLICYFORK in their wording), but they're not subpages of it. Again, you could nuke the main MoS page, and all the rest of them would be unaffected, other than by needing cross-references in them updated. Some MoS pages do have a handful of actual subpages, and they're correctly tagged as information pages, supplements, etc.; redirs to them should be and probably all already are tagged with {{R to subpage}}. There are only about half a dozen of these.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  04:02, 16 December 2017 (UTC)

• All MOS shortcuts, and all WP shortcuts in mainspace, should be moved out. Put "WP:" in front of them. Fix all historic uses. The few editors who use them can get used to this change. Mainspace should be kept clean, mainspace is mainspace, everything in mainspace is part of the encyclopedia, and mainspace redirects must only redirect to mainspace pages. Concerns such as newcomer barriers and simple downstream uses of the product far outweigh sentimentally sticking with an old mistake. No objection to creating a new MOS namespace, except for the concern that MOS aficionados (as clever and correct they might be) already take themselves too seriously. --SmokeyJoe (talk) 05:25, 15 December 2017 (UTC)

  I am not adverse to this. Even the venerable MOS:CAPS has less than 2000 uses. All the best: Rich Farmbrough, 09:43, 15 December 2017 (UTC).
  

  I have probably used MOS:DAB tens of thousands of times in edit summaries - pretty much any time I have edited a disambiguation page to bring it in line with the MOS. bd2412 T 02:54, 16 December 2017 (UTC)

  Those edit summary links would then have to rely on the new link being provided in the deletion summary. —SmokeyJoe (talk) 04:02, 16 December 2017 (UTC)

  If we're going down this route (and I don't know that I'm opposed) then there should be a period of deprecation before deletion - convert the MOS: shortcuts to soft redirects listing the new correct WP: alternative, specially highlighting any where the bit after the colon is not the same. Thryduulf (talk) 10:36, 15 December 2017 (UTC)

  @SmokeyJoe: There are no WP shortcuts in mainspace. All WP shortcuts are in Wikipedia: (a.k.a. Project) space. This is because WP: is an alias for Wikipedia: that is defined at the wiki setup level. For example, WP:RCAT is an alias for Wikipedia:RCAT - it is a redirect in Project space; similarly, WP:Categorizing redirects is not a redirect, it is not in mainspace either. I could write Project:Categorizing redirects and it's exactly the same page without need for redirection.

  There should be no need to create a MOS namespace. We already have the Project (Wikipedia) namespace, which "includes Wikipedia official policies and guidelines", and the Manual of Style is most emphatically among the Wikipedia official policies and guidelines. Manual of Style pages should stay there. --Redrose64 🌹 (talk) 21:23, 15 December 2017 (UTC)

  User:Redrose64, MOS:CAP is a WP shortcut in mainspace. —SmokeyJoe (talk) 22:43, 15 December 2017 (UTC)

  Not to put too fine a point on it, technically you're both correct. "WP" has more than one meaning, and just as a "template shortcut" is defined by whether or not the target page is a template regardless of the namespace in which the redirect is found, a "project-" or "WP shortcut" is defined the same way.  Paine Ellsworth  ^put'r there  19:12, 17 December 2017 (UTC)

• Yes, {{r to subpage}} is appropriate for manual of style "subpages" largely per M.Clay1's first bullet point because they are technically subpages (whether they are "independent guidelines" is beside the point, though I lean toward SMcCandlish's point of view on the matter), and {{r to project namespace}} is obviously appropriate. {{r unprintworthy}} may be redundant per SMcCandlish. I oppose a MOS-shortcut rcat because it is too specific; it opens the door for other rcats for certain types of policy and guideline pages, and there is no reason to do it in this case and not all cases. — Godsy ^(TALK_CONT) 20:44, 15 December 2017 (UTC)
• I'm not sure what to think in the broad sense as the situations seem, as stated quite clearly above, to be very different here depending on which we're talking about. I find myself thinking yes indeed for {{R to project namespace}} a.k.a. {{R to project page}} as well as {{R from shortcut}} and {{r to subpage}}. With Godsy, SMcCandlish, and others' opinions making sense to me, I'm an uncertain no for {{R unprintworthy}}. CoffeeWithMarkets (talk) 22:21, 17 December 2017 (UTC)

  Thank you, CoffeeWithMarkets – please let me know if there is anything I can do to help with your uncertainty.  Paine Ellsworth  ^put'r there  02:40, 18 December 2017 (UTC)

  And why on earth would you support {{R to subpage}} on these, after I've explained in great detail, twice, why that doesn't pertain? If it comes to it, I'm going to mass-RM them all "Wikipedia:Manual of Style (foo)" names, specifically to prevent this boneheaded bureaucratic and omphaloskeptic hyper-gnome crap effectively downgrading a large number of guidelines into some kind of "sub-guideline" that people will then feel they have more of an entitlement to ignore at their pleasure and without a legit WP:IAR reason. Please take this seriously; see the forest, not just the nit-picking maintenance tree several of you are over-focusing on. [I mean that in the nicest way, being a nit-picky gnome myself, but this isn't just frustrating, it dangerous to MoS stability, and that can potentially impact millions of articles.]  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  11:09, 30 December 2017 (UTC)

  As I have already mentioned, I am (or was) leaning very strongly toward your depiction of certain pages that just happen to have a solidus a.k.a forward-slash (/) in their page title to be something other than a "subpage". Judging by your raspy response above, you seem to have not gotten that, yet, so allow me to reiterate: even though I fall short understanding exactly what you mean, I can see that your explanation thus far as to why certain MoS pages that just happen to be titled with a solidus are not to be considered "subpages" contains merit. My only real problem is in how to easily tell the difference between what you consider is not a subpage and what actually is a subpage. In the past, it was easy to tell a subpage because the solidus defined the page as a subpage. Now that you don't want that to be the case anymore, it would help a good deal if you would please show some way that your "non-subpages" can be easily shown to be different from "subpages".  Paine Ellsworth  ^put'r there  15:24, 31 December 2017 (UTC)

  If it would be helpful, let me provide an example. On my talk page, you mentioned that WP:Manual of Style/Accessibility is one of a handful of exceptions to your non-subpage rule, and that those pages that are not actually subpages are "stand-alone" project pages. How would you write that into a guideline that would easily explain to editors precisely what you mean? How, for example, can the accessibility guideline NOT be considered to be a stand-alone project page, and yet, the Wikipedia:Manual of Style/Capital letters page IS a stand-alone project page?  Paine Ellsworth  ^put'r there  15:47, 31 December 2017 (UTC)

  @Paine Ellsworth: I must have been unusually unclear in the user talk thread; WP:Manual of Style/Accessibility is not an exception, and is a guideline. It has (not is) a bunch of information subpages that are not guidelines and are subpages of it (not of the main MoS page). The pages under the WP:Manual of Style/ sub-namespace that are subpages and are not guidelines don't have {{Guideline}} banners on them, but {{Supplement}}, {{Information page}}, {{Howto}} or whatever, and are clearly subpages providing additional (mostly technical) information. (Plus there are some {{Failed}} proposals retained for historical reasons.) See Special:PrefixIndex/Wikipedia:Manual of Style/Accessibility, for example. Most of these things are properly tagged and categorized, and redirs to them should have {{R to subpage}} on them. But a redir like MOS:ACCESS should not because it's going to a guideline which just happens to have "/" in its name.
  [Thinking back, I recall that the rationale for the "Manual of Style/Foo" pattern instead of "Manual of Style (Foo)" was to imply a WP:CONLEVEL authority hierarchy, to avoid misperception of topical MoS pages as alternatives to rather than subject-specific applications and refinements of the MoS. Given various attempts to try to make "WP:Naming conventions (foo)" pages immune to WP:GNG and be substitutes for it, and persistent misinterpretation of various "WP:Naming conventions (foo)" ideas as somehow not subject to the basic WP:CRITERIA policy, this wasn't an idle concern, in retrospect.) Another idea was that the MoS is like a book with "chapters", but I don't think anyone really thinks of it that way. It's pretty much pure WP:SUMMARY style: an overview page branching out into many topically specific, related pages that stand alone and are not fragmentary but which should be kept in agreement with it and with each other.]  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  05:39, 1 January 2018 (UTC)

  I see where I went wrong and misconstrued your first bullet on my talk page, the statement within parentheses of which went "with a handful of exceptions, like actual supplementary subpages of WP:Manual of Style/Accessibility". I still tend to agree with you on this point, and I see that if the header of a solidus page has "guideline" in it, then the page should be viewed as stand-alone and not as a subpage of the Manual of Style. That's easy enough. So far, the scope of this as discussed has only included MoS pages. In your opinion does this also apply within a wider scope? such as other project pages besides the MoS? perhaps even template pages presently viewed as subpages but that are actually stand-alone templates, meta or otherwise? perhaps other namespaces? What do you perceive as the potentially expanding scope of this "solidus page but not subpage" illumination?  Paine Ellsworth  ^put'r there  01:21, 2 January 2018 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Bad example

The example redirect 24 Heures (newspaper) used on this page isn't categorized anymore. --Kliituu (talk) 12:19, 14 June 2019 (UTC)

Why categorize redirects anymore?

I don't think we're making a print version of the encyclopedia anymore, so the printworthy/unprintworthy aspect seems to be not useful anymore since we don't need a paper index. Is there another reason why rcats are still helpful? I did look at this page first but I couldn't really grasp why categorizing redirects should still be encouraged, although leaving in the old ones wouldn't hurt unless they confuse new people and make them feel overwhelmed. I probably missed something. It might be worth having a section that brings this importance out at or near the beginning. Thanks in advance, Geekdiva (talk) 01:31, 27 July 2019 (UTC)

Maintenance categorisation.  Nixinova  T  C  23:52, 16 August 2019 (UTC)

Redirect categorisation serves a variety of purposes, including helping the search engine rank results (redirects from typos are pushed down relative to redirects from alternative names), helping track links that need fixing (e.g. links to redirects from misspellings), and telling editors why the redirect is there (as this is not always obvious). – Uanfala (talk) 21:19, 4 November 2019 (UTC)

I agree, and would go further to say that every redirect in Wikipedia should have at least one categorization, even if it is obvious. There are other editing tasks for which classification of redirects will be useful. bd2412 T 04:40, 5 November 2019 (UTC)

I agree as well. Additionally, the printworthy/unprintworthy distinction can be used for appearances in other indexes e.g. search suggestions. Thryduulf (talk) 09:08, 5 November 2019 (UTC)

Do redirects from typos/etc. need to additionally be tagged as unprintworthy?

A disagreement has arisen on Talk:Pronounciation#R unprintworthy. There Paine Ellsworth expressed the opinion that redirects should always be tagged with either {{R printworthy}} or {{R unprintworthy}}, even if they're already tagged with more specific tags (like {{R from misspelling}}) that already classify the redirect with regard to printworthiness. Is this the general practice? – Uanfala (talk) 21:19, 4 November 2019 (UTC)

I have never added printworthy/unprintworthy rcat templates. I let more specific templates make that categorization.Plantdrew (talk) 22:47, 4 November 2019 (UTC)

If I know a more specific template makes the categorisation then I don't bother adding it specifically, unless for some reason it's different to the usual. If I'm not sure then I usually add one anyway. Even if one is not strictly necessary, don't remove it unless it is incorrect though. Thryduulf (talk) 09:11, 5 November 2019 (UTC)

To editors Uanfala, Plantdrew and Thryduulf: thank you for your responses and concerns! The basis for adding {{R printworthy}} or {{R unprintworthy}} rcats to any and all redirects in mainspace is described in the essay on printability, and in a recent discussion with editor Black Falcon on the talk page of Template:R from alternative language. Bottom line is that the main reason for tagging mainspace redirects with one or the other of the printability rcats is to convey information about the category sorting to editors who come to the redirect page. When an rcat such as {{R from misspelling}} tags a redirect, the info about unprintworthiness is not conveyed unless the unprintworthy rcat also tags the redirect. Categorization takes place, yes; however, that can be executed with a simple [[Category:Unprintworthy redirects]]. Templates are used to tag redirects mainly to convey information. P. I. Ellsworth, ed. ^put'r there 11:37, 20 November 2019 (UTC)

Well, if there really is a need for redirects from misspellings to also display the printworthiness tag, then surely it's better to have that tag automatically displayed by Template:R from misspelling rather than have editors add it individually to all redirects concerned? – Uanfala (talk) 13:14, 20 November 2019 (UTC)

I did that once, several years ago, and was promptly complained to by an editor about the clutter. Some redirects, you see, have two or more rcats that auto sort to a printability rcat. So having each of those exhibit the text of the printability rcat meant that several renditions of the same printability text appeared on some redirects. I had to agree that the clutter was inexcusable, and I removed that ability from auto-sorting rcats like {{R from misspelling}}. It's so much better to have only one rendition of the printability rcat text on a redirect than to have two or more renditions of the same text on that redirect. P. I. Ellsworth, ed. ^put'r there 06:36, 21 November 2019 (UTC)

Well, in that case the template that should display the tag is {{Rshell}}. It shouldn't be too difficult to tweak it so that it checks if any of the rcat templates it contains has obligatorily printworthiness, and display a tag accordingly. At any rate, that's something that will need to be proposed and discussed first. I take it that we agree that individually tagging for printworthiness on each of the millions of redirects out there is not an option. – Uanfala (talk) 14:34, 21 November 2019 (UTC)

If what you propose could be done, I don't know how to do it not for lack of trying. As for tagging the millions of redirects, even with today's growing number of editors who get involved with redirect categorization (it's a rather good Wikignome occupation) the vast majority of redirects still need sorting of any kind, not just printability, and it takes no more time to add a printability rcat to a redirect than it does any other rcat. So no, at present individually tagging redirects is the only option there is. Printability tagging usually means editors must make a decision, a choice. Several rcats that normally default to one or the other of the printability rcats have the ability to be altered by editors. {{R from misspelling}}, for example, defaults to unprintworthy; however, an editor can change that to printworthy by using its |2= parameter. P. I. Ellsworth, ed. ^put'r there 00:22, 22 November 2019 (UTC)

Well, if your intention is to individually tag all redirects from misspellings that have no other rcats with {{R unprintworthy}}, then I ask you to please not do that manually, but put it up for discussion as a bot request, as this involves repetitive and predictable edits that affect almost all of the 36,000 redirects tagged as misspellings. Personally, I continue to fail to see the point of such additional tagging (the {{R from misspelling}} tag is already explicit enough, and it already automatically makes the unprintworthy categorisation). – Uanfala (talk) 19:15, 24 November 2019 (UTC)

You ask me to do it as a bot request rather than manually, and yet the end result would be the same... with one tiny exception: bots cannot decide between printworthy and unprintworthy, bots won't see other needs such as other rcats needed, replacing incorrect rcats and so on. Just don't understand your idea here. What exactly is so bad about a bunch of WikiGnomes seeing to it that redirects are correctly categorized and supplying information to editors??? P. I. Ellsworth, ed. ^put'r there 01:16, 25 November 2019 (UTC)

I don't think the end result will be the same because I believe that if that's put up for discussion as a bot request, it will be likely turned down as an unnecessary task. And if it does get accepted, then it will be performed by a bot that users will be able to easily hide from their watchlists. – Uanfala (talk) 01:46, 25 November 2019 (UTC)

Rcat wording/scope/rationale RfC (R from television episode)

FYI

 – Pointer to relevant discussion elsewhere.

Please see Template talk:R from television episode#RfC: The template wording's accuracy.

I've RfCed this because the page has very few active watchlisters other than the disputing parties.  — SMcCandlish ☏ ¢ 😼  06:58, 5 February 2020 (UTC)

Nomination for merging of Category:Redirects from catchphrases / Template:R from catchphrase

Category:Redirects from catchphrases (and Template:R from catchphrase) have been nominated for merging with Category:Redirects from slogans (and Template:R from slogan, respectively). You are invited to comment on the discussion at the categories' and templates' entry at Categories for discussion. Thank you.  — SMcCandlish ☏ ¢ 😼  07:04, 5 February 2020 (UTC)

Printworthiness

Currently, printworthiness is indicated for ~2 million out of ~11 million redirects. To facilitate adding printworthiness, and assuming that all redirect should have at least two rcat tags (one for printworthiness and at least one descriptive rcat), what do folks think about displaying printworthiness via {{Redirect category shell}}? This would require updating the shell template to add a named parameter, e.g., {{Redirect category shell|printworthy=(yes/no)|...}}. -- Black Falcon ^(talk) 20:30, 30 November 2019 (UTC)

By my count using the printworthy and unprintworthy categories, there are around 3 million redirects that have been categorized as to their printability, 486,064 as printworthy and the rest as unprintworthy. How did you come by the 11 million figure? Does it represent just mainspace redirects or is it the number of all redirects on the project? There used to be a tool that did these counts, but I can't find it now.

I like the idea of the shell with the |printworthy= parameter. It would have to be passed automatically with every transclusion of the shell, and it would have to be passed as "|printworthy= |" so editors would only have to type "yes" or "no". One present problem is that editors don't seem to understand how important it is to tag a mainspace redirect with either the printworthy or the unprintworthy category, so they decide not to decide, and they won't manually add either of the rcats. I've tried to stress this importance at WP:PRINTABILITY; however, the applying of it has been slow-going. Unless editors have a tool like Twinkle or TemplateScript to add rcats in the blink of an eye, they appear to be loathe to taking the time to add the rcats manually. So unless it is made easy as possible, editors will mostly ignore the printworthy= parameter. PI Ellsworth  ed. ^put'r there 16:19, 5 December 2019 (UTC)

Would a Category:Redirects of undetermined printworthiness or similar name be useful? Thryduulf (talk) 18:49, 5 December 2019 (UTC)

Assuming you mean to have such a category bot-applied using the lack of either the R printworthy or R unprintworthy rcat, there would be millions of redirects ending up in that category. Since bots can't make the printability decision, and since there are still relatively few editors who categorize redirects on a daily basis, such a category would be next to impossible to monitor and massage. However it would at least show the entire backlog of redirects that need to be categorized for printworthiness. PI Ellsworth  ed. ^put'r there 03:26, 6 December 2019 (UTC)

The "11 million" figure is from Wikipedia:Database reports/Page count by namespace and represents redirects across all namespaces. I do not think there is an easy solution to the issue issue you highlight in your second paragraph (or, at least, I cannot think of one), but adding the parameter will at least make editors more aware of redirect printability. If there are still no objections after a few more weeks, I will test adding a parameter to the template and proposed corresponding updates to WP:REDCAT. -- Black Falcon ^(talk) 04:45, 15 December 2019 (UTC)

To editor Black Falcon: okay, then the number of redirects marked "p" or "un-p" can be compared only to the 9 million or so redirects in main article namespace, which is the only namespace in which redirects can be printworthy or unprintworthy. I'm actually pleasantly surprised to find that high a ratio, about 32%, almost a third, that have already been tagged one way or the other. I thought it was lower. Anyway, let me know if you need help with the parameter's sandbox testing. PI Ellsworth  ed. ^put'r there 05:20, 15 December 2019 (UTC)

Weird printworthiness template categorization

A peripherally related thing: I'm finding both:

• [[Category:Templates for Printworthy redirects|Song]] [[Category:Printworthy redirects| ]]; and
• [[Category:Templates for unprintworthy redirects|Song]] [[Category:Unprintworthy redirects| ]]

pairs at the same time (sometimes all four not just a pair) on a lot of Template:R from whatever/doc pages, such as at {{R from song}} (though it is not consistently being done at all rcats even of the same general sort, such as for creative works of various kinds).

First off, I don't think it very plausible that song titles and similar things are very often unprintworthy; the cases they're unprintworthy are going to be outliers. Second, it's confusing to have these categorized as both printworthiness and unprintworthiness tags. Third, I don't see any point to these categories being done in pairs. That is, these templates may belong in a "Templates for ..." category, but not a category for actual redirects. Fourth, I question anyway the usefulness of listing them even in either of these "Templates for" categories, because they are not actually templates for [un]printworthiness; they do not have any code in them about that. "Templates that can be used for things that are [un]printworthy according to some other template" is not synonymous with "Templates for [un]printworthy redirects", and it really applies to virtually all rcats, anyway.

So, I'm proposing removing all four of these categories from all rcat templates/doc pages that do not have printworthiness code build into them, like {{R printworthy}}, {{R unprintworthy}}, and a few specialty one I remember running across at some point.
 — SMcCandlish ☏ ¢ 😼  07:20, 5 February 2020 (UTC)

Related TfM

FYI

 – Pointer to relevant discussion elsewhere.

Please see Wikipedia:Templates for discussion/Log/2020 February 5#Template:R to anchor 2 – to merge into Template:R to anchor, and fix the latter to stop auto-categorizing things as unprintworthy (which may explain a big chunk of the unexpected ~32% results that Paine Ellsworth mentioned above).  — SMcCandlish ☏ ¢ 😼  09:20, 5 February 2020 (UTC)

Don't understand why you would want to remove unprintworthiness from anchor redirects? Have you checked with the team involved with printing the Wikipedia disks? It seems clear to me that they never wanted to include anchor redirects in printed versions of Wikipedia. And my noting above that 32% was higher than I expected was more of a happy note that tells me that a lot more editors than I expected are now including printworthiness or unprintworthiness when they categorize redirects. These rcats, {{R printworthy}} and {{R unprintworthy}} are necessary to the project and should not be tampered with unless it is first discussed with the Version 1.0 Editorial Team. PI Ellsworth  ed. ^put'r there 16:04, 5 February 2020 (UTC)

RfC on categorizing redirects to the same namespace

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Template talk:R to project namespace#RfC: Should we categorize redirects to the same namespace?
 — SMcCandlish ☏ ¢ 😼  19:18, 24 December 2020 (UTC)

wikidata redirect

{{wikidata redirect}} does not work well with Template:Redirect category shell. Should it be converted? — Martin (MSGJ · talk) 12:58, 25 September 2020 (UTC)

It says in the template's documentation that it is not meant to be used in a {{redirect category shell}}. ―Jochem van Hees (talk) 22:45, 24 June 2021 (UTC)

Proposed "R from band name" rcat template

I would like to create an {{R from}} category to sort musical band and group names that redirect to an article on an single person. Examples include Paul Whiteman and His Orchestra, Duke Ellington and His Orchestra, Bob Seger and the Silver Bullet Band, Afrika Bambaataa & the Soul Sonic Force, and Puff Daddy and the Family.

{{R from pseudonym}} and {{R from alternative name}} don't apply to these cases due to the difference in taxonomic level and {{R from subtopic}} is a little too vague. Most of these titles do not have "possibilities".

I propose the names {{R from band name}} or {{R from group name}} but am seeking comments and suggestions before proceeding. Thanks. —  AjaxSmack  14:49, 22 August 2021 (UTC)

Just to be clear, this would not be used for a member of a group redirected to that group, if the member does not have his or her own article, correct? e.g., Dean Felber to Hootie & the Blowfish. Chubbles (talk) 13:18, 29 August 2021 (UTC)

​Correct. {{R from member}} already takes care of that. This new rcat would be for a band name title that redirects to an individual (e.g. Dave Brubeck Quartet → Dave Brubeck, Jimi Hendrix Experience → Jimi Hendrix), a little like the reverse of {{R from member}}. —  AjaxSmack  15:55, 30 August 2021 (UTC)