Wikipedia talk:Redirect/Archive 2016

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 2010

←

Archive 2014

Archive 2015

Archive 2016

I've opened a discussion at WP:AN regarding the community-endorsed deletion of Neelix-created redirects under the WP:G6 criterion. You may be interested in commenting. Ivanvector 🍁 (talk) 18:53, 21 January 2016 (UTC)

Do the WP:BRINT exceptions to WP:NOTBROKEN include all unprintworthy redirects or only misspellings specifically?

It seems that many (all?) templates for unprintworthy RCATs contain text like "should be updated to point directly to the target." --SoledadKabocha (talk) 18:42, 20 January 2016 (UTC)

• You should not automatically bypass all unprintworthy redirects. Redirects from titles with diacritics are valid alternative spellings. Redirects to and from plurals exist in part to avoid e.g. ], which is unnecessarily complicated. Redirects to disambiguation pages should not be bypassed per WP:INTDAB. Redirects from shortcuts like ] are used intentionally. Etc. Gorobay (talk) 19:06, 20 January 2016 (UTC)

Ok, sorry for not thinking harder (and actually looking at some templates) before asking that particular question.

My fault for not wording better what I really wanted to ask, though: For those unprintworthy RCATs that do actually say "should be updated to link directly to the target," such as {{R from other capitalisation}}, is there a consensus on whether such wording controls what editors should actually do? Or do you think the templates other than {{R from misspelling}} should be modified not to contain such wording? --SoledadKabocha (talk) 21:57, 20 January 2016 (UTC)

IMO, piped links aren't really worth fixing. However, direct links from incorrect spelling or capitalisation are. For example, the USA uses the M16 rifle, not the M-16 rifle. So probably isn't worth fixing, but is. So I would strongly prefer that there be some sort of redirect tag that makes it clear that the linked redirect is not okay, be it a misspelling, bad punctuation, or whatever. Or am I not understanding the issue? Faceless Enemy (talk) 04:04, 21 January 2016 (UTC)

My understanding is currently as follows: Some templates for unprintworthy redirect categories instruct editors that affected redirects "should be updated to link directly to the target." (The extent to which editors actually do this is a separate issue.) "Some" refers to a carefully-chosen set, and it does not mean "all" or even "most"; my original question was predicated on an incorrect assumption. I should have asked about adding a mention specifically of R from other capitalisation, not of "all" unprintworthy RCATs.

You raise an interesting point, that perhaps there are really two tiers of unprintworthy redirects, those that should be fixed and those that need not urgently be fixed. The distinction depends partly on whether a given link is piped, not solely on the nature of a particular RCAT. I'm not sure how we would make the distinction more visible than the text of the RCAT template, though.

I'm not aware of anything else you have failed to understand. --SoledadKabocha (talk) 06:04, 21 January 2016 (UTC)

There really should be different levels of "unprintworthy" or "misspelled". So Mosin-Nagant vs. Mosin–Nagant probably qualifies as "wrong, but who cares" whereas "Moisin-Nagat" would be "fix ASAP". It would also be helpful to have {redirect from POV}, so when articles used terms like "The War of Yankee Aggression" to refer to the American Civil War, it would be in a database somewhere. Another redirect tag could be {r from unclear}, so even though 9mm redirects to 9×19mm Parabellum, it's pretty unclear (I can think of three other "9mm" pistol cartridges off the top of my head) and should really be specified at the article. Faceless Enemy (talk) 12:50, 23 January 2016 (UTC)

As far as I am aware, the best option we currently have in order to distinguish "mildly unprintworthy" from "strongly unprintworthy" redirects is to explicitly specify {{R unprintworthy}} (or the corresponding unprintworthy/up parameter to {{redr}}) on the latter. However, this makes no difference to categorization, so it is only helpful for editors looking directly at the redirect=no page. There isn't a clear consensus for such use; this is an example of such use on an unnecessary disambiguation, which may not be as strongly unprintworthy as a misspelling. --SoledadKabocha (talk) 07:30, 2 February 2016 (UTC)

Can categories be added to redirects when the categories do not apply to the redirected target article? For example, Hasbara redirects to Public diplomacy (Israel) and there's a category Category:Hebrew words and phrases which is in Hasbara but doesn't apply to Public diplomacy (Israel). Therefore, common sense and logic would deduce that if a category applies to the redirect but does not apply to the redirected target article then it is appropriate as there is no duplication and it is helpful for the user to browse and navigate through in order to get to it.

This could also apply to films that redirect to the director, albums that redirect the artist, books that redirect to the author etc. For example, an editor browing through Category:Year albums, Category:Year films or Category:Year books will not get to the title without the categories being placed on the redirect. Tanbircdq (talk) 19:00, 4 February 2016 (UTC)

• This is standard practice for Category:Surnames. I think it makes sense. Gorobay (talk) 19:15, 4 February 2016 (UTC)

Yes, redirects can be categorized when the category is incompatible with the title of the target page. See WP:INCOMPATIBLE. Plantdrew (talk) 19:17, 4 February 2016 (UTC)

on a topic that may be of interest to those editors interested in the use of redirects on disambiguation pages. See Talk:Committee on Government Operations#Avoid redirects. older ≠ wiser 23:15, 17 March 2016 (UTC)

In 2014, the behavior of redirects was changed so that they change the URL to that of the target page and the target is shown on the redirect page with "redirect=no" in the URL. Now it appears that the target appears as a normal link on redirect pages again. For example, Element (disambiguation) now links to Element instead of Element. GeoffreyT2000 (talk) 21:10, 31 March 2016 (UTC)

Although the redirect in ] is not broken, it is pointless, since the wikilink results in the same look and effect as the direct link ]. I fix such pointless redirects when I spot them.

This reason to bypass redirects is not included in the list of reasons given in the guideline. Any objections to my adding it?  --Lambiam 17:17, 5 April 2016 (UTC)

@Lambiam: No objection from me, but it's not the same as the situation addressed at WP:NOTBROKEN and would only serve to confuse matters if you added it there. NOTBROKEN refers to the reverse form ], and says it should be reduced to ] (for this illustration I'm disregarding the fact that President ] would probably be better). In other words, NOTBROKEN says, "If there is an existing redirect that matches your desired link text, use it." It doesn't recommend bypassing a redirect, but rather not bypassing a redirect. ―Mandruss ☎ 18:04, 15 April 2016 (UTC)

Such redirects are sometimes pointless. Bypassing them is also pointless. Gorobay (talk) 19:09, 15 April 2016 (UTC)

Many editors feel that there is something to be said for clean wikicode, even when there is no visible difference to a reader. The proposed, very brief guideline would not force anyone to do anything; it would merely support those who choose to. ―Mandruss ☎ 20:00, 15 April 2016 (UTC)

Something I thought had been part of the guidance, but which I'm not seeing now, is that it is often perfectly fine to change such redirects in the course of making other edits to a page, but it is of questionable value to edit a page solely to change such a redirect. older ≠ wiser 21:58, 15 April 2016 (UTC)

I've heard similar reasoning opinions, not necessarily in this context. I've never understood it or agreed with it. What, are we conserving space in the page history? Why? Should I avoid correcting my typos in talk spaces because it's not worth the page history entry? No thanks, I oppose discouraging minor improvements when they cost nothing but a miniscule amount of server resources and the time of the editors who choose to make them. I almost never invoke WP:IAR in my editing, but I would in that case. ―Mandruss ☎ 22:14, 15 April 2016 (UTC)

It is questionable that it is an actual improvement, at the last, not in the same category as correcting a typo. older ≠ wiser 23:52, 15 April 2016 (UTC)

If it's justifiable in the same edit as other improvements (see your comment above), it's justifiable by itself. Again, the only difference is the extra page history entry. ―Mandruss ☎ 00:28, 16 April 2016 (UTC)

Whatever floats your boat. If you find making such dubious trivial edits worthwhile, then go for it. I question the value. older ≠ wiser 02:00, 16 April 2016 (UTC)

And "whatever floats your boat" is precisely what I've been advocating. I never said anything to remotely imply that you or anyone else should conform to my preferences. I will oppose any guideline that discourages a type of edit because a majority consider it too trivial to do themselves. ―Mandruss ☎ 02:07, 16 April 2016 (UTC)

That's all well and good for edits that are in fact unquestionably beneficial. I don't agree that applies here and it amounts to edit history pollution to make edits solely for the purpose of edits that are without a clear benefit. older ≠ wiser 02:25, 16 April 2016 (UTC)

You can say that changing ] to ] isn't worth your time, but you can't reasonably say that it's of no benefit whatsoever. That is patently, objectively, demonstrably false. At the very least, it (1) simplifies the wikicode a little, (2) avoids confusing newer editors, possibly encouraging the spread of a bad coding practice, and (3) avoids a pointless redirect each and every time the link is clicked (redirect overhead may be minimal, but no one can dispute that it is nonzero). That's clear enough to me. ―Mandruss ☎ 04:29, 16 April 2016 (UTC)

I'm saying the benefit of making a single edit to correct that sort of thing is questionable. Although it should not a concern for editors, the system overhead involved in saving an edit is magnitudes greater than that of a redirect. As part of a general copyediting effort, there's little problem. I just don't want to encourage editors to go out of their way to make extremely low value edits. older ≠ wiser 11:45, 16 April 2016 (UTC)

the system overhead involved in saving an edit is magnitudes greater than that of a redirect - The former happens once, the latter every time the edit is clicked, to the end of time. And then there are the other benefits I mentioned. In any case, I haven't heard anything about the servers being so close to their capacity that we need to worry about bundling edits in this manner. Computer systems continue to become faster and less expensive. We should avoid self-appointing as protectors of the servers, and leave that to the people in charge of the system, who are in a far better position to do it. ―Mandruss ☎ 17:58, 16 April 2016 (UTC)

By that reasoning we should just let the vandals have at it, since they know far better than we about what they want from Wikipedia. older ≠ wiser 18:07, 16 April 2016 (UTC)

Huh? Sorry, when you start with reaches like that, it's a strong sign that we're wasting our time. Thanks for the civil conversation. When WMF tells me that the success of the project depends on an edit bundling strategy, I'll support that 100%. Finis. ―Mandruss ☎ 18:12, 16 April 2016 (UTC)

I know that WP:NOTBROKEN is about not bypassing redirects, but that section of the guideline already contains a paragraph listing Good reasons to bypass redirects, and I don't think it would increase the confusion (if any) caused by listing such good reasons there if this "exception" to NOTBROKEN is added to the five already gived there.  --Lambiam 22:30, 15 April 2016 (UTC)

@Lambiam: Ok, thanks for that clarification, but I still don't think they are the same thing. One (your example) is omitting an unnecessary redirect, and the other is coding an article title (in parameter 1 of a piped link) in order to bypass a redirect. They both involve something unnecessary, and they both involve redirects, but they are not the same. ] and ] are not the same animal, and it would be confusing to address them in the same context. ―Mandruss ☎ 22:47, 15 April 2016 (UTC)

I don't think it would be good to say, "It is never useful to code a redirect as parameter 1 of a piped link." If such a case involves a redirect with possibilities, that coding would actually make sense. In the form ], A may be retargeted at some point, or it may become an article in its own right. Obviously your example is not such a case, but any new guideline would have to make this distinction clear. ―Mandruss ☎ 23:45, 15 April 2016 (UTC)

Sorry, but I don't understand. In what sense do you mean "code"? All wiki code is code to me. What is not the same thing as my example? Of course ] and ] are not the same, because they result in a different look on the page.

Do you agree that one should correct the spelling mistake in ], even though the redirect is not broken? This is one of the "exceptions" listed at Good reasons to bypass redirects. But what then if you see ]?  --Lambiam 23:49, 15 April 2016 (UTC)

In my opinion the "Kennedie" one should not be listed as an "exception", because it's not an exception. It's a case where the rule has confused some editors, but the rule itself, as stated, does not cover this case, so no exception is needed. Perhaps a clarification is needed. --Trovatore (talk) 23:55, 15 April 2016 (UTC)

I'm merely saying that omitting A (a redirect as parameter 1 of a piped link) is not the same as coding (not omitting) B (an article title as parameter 1 of a piped link), and they should not be treated as the same.
] -> ]
is not the same as
] -> ]
but you are suggesting that we should refer to both as "bypassing a redirect", and in the same context. By your definition, any simple wikilink that specifies only the article title is "bypassing a redirect". ―Mandruss ☎ 00:04, 16 April 2016 (UTC)

Note the following statement at WP:NOPIPE: "...while ] is unhelpful, ] is helpful." This new guideline and that statement would have to be reconciled to avoid contradictory guidance, beginning with understanding what it's talking about. It may be referring to the redirect-with-possibilities case, which is rare and should be mentioned in this guideline anyway, as I said above. In most cases, ] is not helpful, which is why we're having this discussion. ―Mandruss ☎ 20:45, 16 April 2016 (UTC)

Should editors be directed to unpipe redirects in "See also" sections? -- Beland (talk) 18:16, 25 January 2016 (UTC)

---

I propose adding to the list "Good reasons to bypass redirects include:" the following:

• Links in "See also" sections. Only linking to the real article name makes it easier for readers to determine which articles they have already read.

I fix this sort of link all the time. -- Beland (talk) 18:47, 22 January 2016 (UTC)

No one replied to this RFC, so I assume there's no strong objection to doing so. -- Beland (talk) 17:23, 8 February 2016 (UTC)

Beland, I have removed your "See also" exception again.

I think, that it is, in general, not a good idea to replace links to redirects in "See also" sections unless they were obviously unsuitable in this context (and, assuming good editorial judgement, in this case they wouldn't have been listed there in the first place).

All the reasons stated (in WP:NOTBROKEN/WP:NOPIPE and elsewhere) for why unbroken redirects should not be "fixed" apply to links in "See also" sections as well. Per WP:SEEALSO, links in "See also" sections "should reflect the links that would be present in a comprehensive article on the topic", that is, the link labels will often be terms relevant in the context of the original article, but not yet discussed in the article body. Article titles of redirect targets, however, may use a different terminology or be in another context, and it would look odd or even confuse readers, if such article titles were listed in the original article. Conceptually, they don't belong there. One reason for redirects to exist is to cover this up and function as a "bridge", so that an article can link to terms genuinely relevant in its own context.

For as long as the redirect target actually explains the term (and therefore is relevant and not broken), editors of the original article should not have to bother how and where exactly this info is explained elsewhere. Also, redirects might point to anchors in their corresponding target articles. Replacing them, we'd lose information or were forced to use pipes (which we shouldn't). Further, assuming that only relevant terms are listed under "See also", most any redirect listed there could potentially become an article of its own later on, so not going through those redirects we'd actively work against build the web and make it unnecessarily difficult to carry out changes in the organization of information elsewhere. We'd thereby hinder the further growth of Wikipedia.

I understand your point that replacing the redirects with direct links makes it easier for you to recognize already read target articles, but this is based on a number of weak assumptions. Unless someone would exactly remember most article names visted in the past, the approach depends on a browser displaying visited pages differently (not all browsers do so, and not in all contexts). Also, this is based on the idea of always reading whole articles, whilst redirects often point to sections or anchors in an article (so, following your idea, a reader might dismiss an article already seen, although a different section was read in there). Basically, this won't work in general. Navigation boxes and actual outlook articles seem to be more suitable for your proposed systematic study.

To sum it up, the labels of links in "See also" sections should be relevant in the context of the original article no matter if they are direct links to articles or redirects. However, replacing relevant redirects by direct links (or pipes) in "See also" sections is not (unless one of the other exceptions would apply), in fact it would be detrimental most of the time.

--Matthiaspaul (talk) 16:43, 7 May 2016 (UTC)

This edit request to Wikipedia:Redirect has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

The "Page mover" right has been created. Can you please replace the following sentence: Currently these groups are administrators, bots and global rollbackers. with this one: Currently these groups are administrators, bots, page movers, and global rollbackers. under the "Suppressing redirects" section? Note the addition of the serial comma before "and". 63.251.215.25 (talk) 17:21, 24 May 2016 (UTC)

Done Mlpearc (open channel) 17:26, 24 May 2016 (UTC)

Although ArkivMusic may be a subsidiary of Steinway Musical Instruments (or, may not be: see Paulson & Co.), it seems to me that whatever benefits this redirect has are negated by the confusion it creates when two lines appear in the drop-down list, regardless of who owns whom. (By the way, I hope that this very specific question is appropriate here. If not, please tell me where to pose it. Thanks CWBoast (talk) 01:11, 8 June 2016 (UTC))

@CWBoast: this is a fine place to post this question, but a better place would be Wikipedia:Redirects for discussion if you think that the redirect should be changed or deleted, and you would like to solicit feedback from the community. My view of consensus from past discussions on URL redirects is that generally we keep them if they are a redirect from a domain that is related to the target, for example in this case I think it makes more sense for the redirect to target ArkivMusic rather than its parent company, whichever it is. Would you like help posting at RfD? Ivanvector 🍁 (talk) 13:12, 8 June 2016 (UTC)

I've been talking with Jetstreamer about a whether it was correct for me to edit and rename a link from Malaga → Málaga. He reverted my edit saying that the policy was WP:UNBROKEN. I can understand that both links go to the same place, but I would think it would be preferential to have the correct name visually on the page, especially since there is already a link to Málaga Airport (and not Malaga Airport) right next to one of the links he reverted. Looking at WP:UNBROKEN, I don't think it applies. The edit has a noticeable effect on the rendered page, displaying the city name spelled correctly.

Since that first edit, he has also reverted another where I changed Sao Paulo → São Paulo and Lulea → Luleå. Again, on the page there is already links to the correctly spelled São Paulo-Guarulhos International Airport, Luleå and Luleå Airport.

I can't find any policy on WP:PLACE, MOS:LINK or WP:TYPO saying that I shouldn't have changed those links to reflect the actual and correct spelled names of those cities, especially since the correct spellings are already on said pages.

Thoughts? ~ Ablaze (talk) 07:30, 30 June 2016 (UTC)

I don't think UNBROKEN advice on not bypassing redirects applies in the cases. UNBROKEN does say "Spelling errors and other mistakes should be corrected. Don't link to a misspelled redirect". Variations in diacritics aren't exactly the same as spelling errors, but it would seem desirable to link to the article title that uses the diacritics correctly rather than the redirect lacking diacritics. Plantdrew (talk) 15:05, 30 June 2016 (UTC)

Malaga is neither a spelling error nor a mistake but the English name of a city, as the other two examples above also are.--Jetstreamer ^Talk 22:38, 1 July 2016 (UTC)

Are you saying since this is English Wikipedia, we should only be using characters from A-Z and not ones such as in Swedish Ö, Ä or Å which are separate letters in their alphabet? I can't find any instance on those city articles in English where their "English name" is used. Why do you revert my changes saying Malaga is the English name, yet leave Málaga and other non-"English named" cities remain in the article?~ Ablaze (talk) 08:04, 2 July 2016 (UTC)

That is not a case for UNBROKEN, which applies only to piped links. For example, UNBROKEN says that ] - Málaga City - is preferable to ] - Málaga City - because it uses the redirect as it was intended to be used. It says we should not bypass the Málaga City redirect just to save a few computer cycles. It does not mean, "There is rarely a need to change a working redirect", which appears to be how Jetstreamer is interpreting it. You can debate the change on other grounds, but not per UNBROKEN.
Those "other grounds" are wrong venue here, but English Wikipedia uses diacritics all over the place and I see no reason to deviate from the article title in this link. In fact, the opening sentence at Málaga links to Province of Málaga despite the existence of a redirect for Province of Malaga. The applicable guideline is, quite predictably, WP:DIACRITICS. ―Mandruss ☎ 09:30, 2 July 2016 (UTC)

As Mandruss pointed out above, it seems I've been misinterpreting WP:UNBROKEN. I'm sorry for the inconvenience. In particular, I apologise to Darranc.--Jetstreamer ^Talk 23:13, 3 July 2016 (UTC)

No worries. It is always good to seek clarification (and it was a good discussion) and I'm sure there is a guideline somewhere else that I'm misinterpreting. ~ Ablaze (talk) 10:30, 4 July 2016 (UTC)

According to Warning1 for anchors, the anchor name and the section title of the redirect can not be the same. However, I have previously created situations like this (where the anchor and section title are the same) and it seems to work. The redirects I am talking about are Old War Office Building and War Office building, both linking to the War Office building section of the War Office. My question is why are these redirects working? Am I misunderstanding or misusing something or is this warning not applicable or no longer working?. -- FactualCollector7d1 (talk) 23:40, 19 July 2016 (UTC)

It's talking about when you add an {{anchor}} to a page. If the anchor has the same name as a section title there will be multiple anchors on the page with the same name (as section headings are also anchors), which is invalid HTML. You see exactly the same issue on pages with multiple sections with the same name - sometimes you end up at the first on the page, other times you end up at the one you wanted (if different). Thryduulf (talk) 01:47, 20 July 2016 (UTC)

An IP editor is citing WP:NOTBROKEN as justification for replacing anchored links with obscure redirects. For example, using the redirect Scree's test to refer to the entire section factor analysis#Criteria for determining the number of factors, in a piped link regarding determining the number of factors of a polynomial. The text of the article is not specifically about Scree's test, though. So I am of the opinion that a piped link to the redirect is not a good idea here. But the guideline here suggests that redirects are always preferable to anchor links. Another example of the same issue in the same article is a link to secular equation, which is an obscure synonym of characteristic equation. Are redirects always preferred to anchor links, even when they are obscure seldom-used terms? Sławomir Biały (talk) 14:38, 23 July 2016 (UTC)

Redirects are usually preferred to anchor links when there is a possibility that the section could be expanded into an article or split off in some other way, as that way one only link needs updating. However if you feel a redirect is not useful (e.g. because it's an obscure synonym or poorly named) then you should nominate it at WP:RFD for discussion. Thryduulf (talk) 14:50, 23 July 2016 (UTC)

I think this misses the point. Scree's test is a perfectly legitimate topic for a separate article. But if that article were replaced, the piped link to the section of factor analysis would need to be replaced, because Scree is a specific test, but we want a general link to that section of the article. The redorect Scree's tedt is being used as a synecdoche. The redirect secular equation is probably useful, for someone typing this into the search bar, but I don't think it should be used in article space simply because redirects are "better". That's imposing a marginal term for something, violating NPOV. Sławomir Biały (talk) 16:17, 23 July 2016 (UTC)

Participants here may want to comment on this discussion of when it reasonable to use bolded "title" text in subsections of articles. Dragons flight (talk) 10:52, 26 July 2016 (UTC)

I've been reverted for replacing ] with ]s. My replacement was part of more significant cleanup; Such replacement clearly does not justify its own edit. This is not directly addressed in WP:NOTBROKEN. {{R with possibilities}} is not in play here. It is not introducing any additional wikicode. The change does result in simplified popups. Does anyone have a read on this? I'd be happy to improve WP:NOTBROKEN if there's consensus. ~Kvng (talk) 17:42, 30 July 2016 (UTC)

I don't think that simplifying popups is comes anywhere near enough benefit to justify any change to WP:NOTBROKEN. I wouldn't have reverted for that, but equally I would discourage making changes like that as it adds complexity to diffs for essentially no gain whatsoever. Thryduulf (talk) 21:01, 30 July 2016 (UTC)

In general, you should avoid this kind of change; there's no reason to change the link in the way that the edit did. There were a other things that you changed that should not be, such as changing the reference formatting. If the goal was to alphabetize the see also links, that could be done on its own without the other changes. That would make the diff easier to read, maximize the benefit of the edit, and reduce the chance that someone else will undo it. — Carl (CBM · talk) 21:53, 30 July 2016 (UTC)

I assumed there was a gray area between what's described in the "reasons not" and the "good reasons" sections of WP:NOTBROKEN but what I'm hearing is that "good reasons" is the complete list of acceptable modifications and "reasons not" is an incomplete list of examples of unacceptable modifications. ~Kvng (talk) 14:04, 31 July 2016 (UTC)

No, both lists are incomplete and there is a grey area, but this example does not fall into that grey area. Thryduulf (talk) 14:08, 31 July 2016 (UTC)

Please explain why this does not fall into the gray area. I don't see any of the points in either list applying to this situation. ~Kvng (talk) 14:59, 31 July 2016 (UTC)

Also, I just noticed that {{r from plural}} offers the following, "do not replace these redirected links with a simpler link unless the page is updated for another reason" (my emphasis). I did have other reasons for the update (list sorting, removing a duplicate link , adding {{foldoc}}). Is this advice wrong? ~Kvng (talk) 14:59, 31 July 2016 (UTC)

Clearly not a NOTBROKEN issue, as that guideline is only about bypassing redirects using piped links (this is quite evident in the first paragraph of the guideline). There is no piping involved here. For other misinterpretations/misapplications of NOTBROKEN, see #Question changing place names and WP:UNBROKEN, above, and this ANI thread. Strongly oppose any change to NOTBROKEN for this, and that will include RfC if necessary.
However, since misinterpretation seems to be an ongoing problem, I would not oppose the emphasis of the point with something like this: "This guideline applies only to bypassing redirects using piped links."
But some of the NOTBROKEN concept applies here. If at some point in the future we created a separate article titled "Telecommunications", I think we would most likely want that link to automatically target that new article, not Telecommunication. So it would make some sense to use the redirect. If you say that such a new article is extremely unlikely, then it's simply a matter of coding simplicity, and the redirect is the simpler form. The "popup" (tooltip) will read "Telecommunications", which means "some article which Wikipedia currently believes most closely applies to the term 'telecommunications'". The exact title of the target article is not the point. At least that's my view of those tooltips, which I strongly suspect are rarely read by readers anyway (I never read them, FWIW). ―Mandruss ☎ 18:21, 31 July 2016 (UTC)

I've seen and have been myself for years formatting a link like ]s in articles where plurl is apporiate, also iirc I was told years ago this type of link format helps bots, for ease of page identification, I think. Mlpearc (open channel) 19:22, 31 July 2016 (UTC)

@Mlpearc: - Thanks for the support, but you may have misread me. I'm supporting ]. ―Mandruss ☎ 19:26, 31 July 2016 (UTC)

Seems I did. I've adjusted my post :P thanx. Mlpearc (open channel) 19:31, 31 July 2016 (UTC)

(edit conflict) ]s is just a shorthand way of writing ] and so everything about piping applies, even if there is technically no use of the pipe character. Thryduulf (talk) 19:33, 31 July 2016 (UTC)

If that's so, then the guideline needs a major rewrite. I like to take guidelines at face value rather than applying my own original-research-like interpretations. ―Mandruss ☎ 19:35, 31 July 2016 (UTC)

Agreed although the rewrite is not necessarily major. Let's figure out if we have consensus on what we want before worrying too much about how to codify it. I've repeated the nut of the question below. Should we open an RfC or is this too minor of a detail to use any more of our time on? ~Kvng (talk) 21:13, 31 July 2016 (UTC)

@Mlpearc: I beleive that everyone appreciates that the ]s form is best for plural context. My question is, does WP:NOTBROKEN discourage changing existing links to use this form instead of pipes or {{r from plural}} redirects? ~Kvng (talk) 21:13, 31 July 2016 (UTC)

IMO, the guidance on {{r from plural}} is accurate. There is little value in editing a page only to change these links, but there is no harm in changing them to direct links and arguably makes the wikicode easier to read. older ≠ wiser 21:53, 31 July 2016 (UTC)

The discussion above mostly missed the actual reason why I reverted KVNG's edit. As I explained on the talk page, telecommunications is not the plural of telecommunication. Telecommunication is the act or process of communicating at a distance. Telecommunications (which is a singular noun) is the science or industry of telecommunication.{{R with possibilities}} is the issue here: we could in principle have separate articles on telecommunications and telecommunication. In any event, the former is the concept referred to in the article, and therefore is the proper target for the link. Mandruss picked up on this, above.--Srleffler (talk) 02:43, 2 August 2016 (UTC)

Thanks for repeating that information here. {{R with possibilities}} is clearly called out in WP:NOTBROKEN and I'm sorry I misinterpreted this as a {{r from plural}} issue. There is still ambiguity around {{r from plural}} and it looks like it will not be resolved by this discussion. For my part, for these cases, I will follow the advice in {{r from plural}} and only improve these links in the context of other improvements. ~Kvng (talk) 13:52, 2 August 2016 (UTC)

I've just started a discussion at Wikipedia talk:Cross-namespace redirects#Newly created CNRs, please comment there. The previous discussion on that page (from November 2014 but still unanswered) would also benefit from input. Thryduulf (talk) 12:24, 10 August 2016 (UTC)

This actually ruins the redirect function. The example code is false and giving people (such as myself) a broken example when copying. Someone reverted my correction, stating this (the code being ruined) is necessary for readability. Is this some type of joke? ....SandwitchHawk.... (talk) 01:52, 18 August 2016 (UTC)

Are you copying the code from the page being displayed, or are you copying it by editing the page and copying the underlying code? If you're copying the underlying code, you're working too hard. The standard across the wiki for producing code examples on project pages is to create printable code that can be cut and pasted from the rendered page, not from the editor. It's not a big deal here but in other code examples it would cause the parser to actually execute the code, and that would break things. The non-breaking space forces the code block to render on a single line, which is preferred because a line break in redirect code would break the redirect. Ivanvector 🍁 (talk) 02:07, 18 August 2016 (UTC)

No, the code is being copied directly from the normal face of the article. Once again, I will remind you the code being presented on the article is incorrect. There is no need to refute this, because it's impossible. I am correcting the code by removing the space between "#REDIRECT" and "]". The non-breaking space provided here breaks the function of the code. It's really simple as that. I also noticed you removed the "&nbsp" (non-breaking space) given in the original line of bad code, and replaced it with a regular space, further complicating matters. There really is no need for this. ....SandwitchHawk.... (talk) 03:09, 18 August 2016 (UTC)

I'm not sure what problem you are trying to solve. The code presented in the article works just fine. I just copied and pasted the first example into a sandbox page, and it redirected as intended. Further, a space between "#REDIRECT" and the link is normal, as you can see by clicking the "redirect" button in the toolbar above the edit box. I have reverted you, and suggest you explain better what you are trying to accomplish before making further changes in the page. --Srleffler (talk) 05:43, 18 August 2016 (UTC)

Oh my F-ing god, I just used the redirect for an article and it wasn't working. Then somebody else came by and deleted the space (the same action I am trying to do here with the code example) and then it magically worked. Do redirects need to be approved by an admin? ....SandwitchHawk.... (talk) 09:08, 18 August 2016 (UTC)

I realize it takes time for the servers to update with the redirect globally, but I would assume the formatting and symbol directly used on the redirect page is parsed locally and instantly appears. Someone specifically came and deleted that space between the redirect command and page link, and that's the exact moment when the redirect actually worked. So I figured the information here on the code example was false. I apologize for assuming any other editors to be in the wrong here, if I am indeed wrong here. ....SandwitchHawk.... (talk) 09:44, 18 August 2016 (UTC)

It seems the edit in question is which shows that a space was removed from between the # and REDIRECT. #REDIRECT ] and #REDIRECT] are the only two formats that will work, # REDIRECT ] will not. I've looked at every example of the code on this page and none have any characters between the # and REDIRECT. Testing in my sandbox shows that when a literal non-breaking space (" ") is used between the REDIRECT and the target name the redirect works as intended but when " " is used it does not . Thryduulf (talk) 10:02, 18 August 2016 (UTC)

There was never any space between # and REDIRECT this is silly ....SandwitchHawk.... (talk) 13:48, 18 August 2016 (UTC)

I was copying the code example directly from the regular face of the article using Google Chrome, I doubt that should pick up the " " which used to be in the article source before one of my reverts, and was placed between #REDIRECT and ]. To simplify matters, the simple space I am trying to remove from the code example should just be removed anyway. ....SandwitchHawk.... (talk) 13:56, 18 August 2016 (UTC)

Looking at this edit by ....SandwitchHawk...., there IS a space between # and REDIRECT in the code, and indeed it does not work. However, in the next edit they removed the space, but the redirect still did not work. I checked, and the character left between REDIRECT and the target is U+00A0   NO-BREAK SPACE, which is broken, so our friend is right about non-breaking spaces. Thryduulf's "literal non-breaking space" is actually just a regular U+0020   SPACE, both on this page and in his sandbox. The following edit by another user removed the space, and we already know that you don't need to leave a space for the redirect to work. Here's what we know:

1. inserting a space between # and REDIRECT does not work.
2. whether there's a space between #REDIRECT and the target doesn't matter, the redirect works either way.
3. a non-breaking space (either #REDIRECT target or an actual unicode no break space) breaks things. Apparently the parser can't see the REDIRECT special word in this case.
4. (side note) redirects are instantaneous, there is nothing to update on the server other than saving the page.

My guess is that VisualEditor interpreted the pasted code as intending to create an ordered list, and inserted the space after the # automatically. I can't seem to enable VisualEditor to test that; I'm not sure if that would be considered a bug. As of right now, all of the instances of the code on WP:REDIRECT, both those wrapped in {{nowrap}} and those employing  , are displaying a regular space, and must have been when SandwitchHawk copied and pasted the code, so perhaps this non-breaking space business is also some kind of VisualEditor quirk? Ivanvector 🍁 (talk) 15:04, 18 August 2016 (UTC)

To redirect a page in Visual editor you must:

1. select the "Page options" button on the toolbar
2. Choose the "Page settings" tab
3. Enable the "Redirect this page to" checkbox
4. Type the destination page name in the "target page for redirection" box that the previous step enabled
5. Click the "apply changes" button, closing the dialog box
6. Click the "Save the page" button on the toolbar
7. Optionally, add an edit summary
8. Click the "Save the page" button in the dialog box

Pasting wikitext code, from whatever source, into the visual editor edit window should never result in anything other than the code being displayed as plain text on the saved page. Thryduulf (talk) 15:16, 18 August 2016 (UTC)

Oh yes, this is getting silly. Yes, I remember placing the space between # and REDIRECT. But that was a regular typo which I quickly caught. I know that format is wrong, so I never considered it to be relevant with anything and forgot about it. But yes, it still remains in the edit history, please disregard. ....SandwitchHawk.... (talk) 15:21, 18 August 2016 (UTC)

• Thank you for clarifying the #REDIRECT function kind sir ....SandwitchHawk.... (talk) 15:26, 18 August 2016 (UTC)

Alright, I got VisualEditor to work; these are the results of my testing:

1. copying the code from WP:REDIRECT and pasting into the VisualEditor does not work.
   • copying the code wrapped with {{nowrap}} produces text wrapped in a <nowiki> block.
   • copying the code with a   in it produces an ordered list. (I didn't save this edit)
2. copying the code from WP:REDIRECT and pasting into the VisualEditor, then switching to the source editor before saving, does not work. You end up with # REDIRECT target, and this seems to be what SandwitchHawk did with the first edit.
3. copying the code from WP:REDIRECT and pasting into the source editor works just fine.
4. in every one of these cases, I end up with regular spaces pasted. I can't figure out where the unicode no break space came from in SandwitchHawk's edit. I'm also using Chrome, but in Ubuntu; I don't think the browser or the platform should affect this.

The way to create a redirect with the VisualEditor involves opening a menu and clicking a checkbox, not editing code directly, so it seems we do need to update the instructions on this page. I'll give it a shot. Ivanvector 🍁 (talk) 15:27, 18 August 2016 (UTC)

(edit conflict × 3) Yeah, what you guys said. Ivanvector 🍁 (talk) 15:27, 18 August 2016 (UTC)

The unicode break between #redirect and target was always there in the article source, before any of my editing, at least thats how i rememeber it. And im not sure how chrome parses these unicode breaks, i would assume a regular space, especially when adding to clipboard in windows10. Not sure how the visual editor effects my clipboard like this too. The code example I copy is through a normal article, unless having the visual edit option enabled gives my browser a different magic article? i doubt this. and i don't know how to place a #redirect into the visual editor, so i switch to source before pasting anything. ....SandwitchHawk.... (talk) 15:44, 18 August 2016 (UTC)

Hmm, as far as I know,   produces a regular space and the browser is coded not to wrap, rather than producing the unicode no break space character. I'm testing by copying the space and pasting into this website, maybe you can test from your system? I could be wrong, but the revision before you edited seems to be displaying regular spaces as well, at least for me. Do you happen to remember which page you were copying the code from? Ivanvector 🍁 (talk) 16:02, 18 August 2016 (UTC)

ok to further clarify, i assume " " is a unicode space, not a regular one. when i mention "unicode space" i am talking about " " placed into the article source, which i think has some effect ....SandwitchHawk.... (talk) 16:06, 18 August 2016 (UTC)

ah, now i understand the unicode no break character is a different character which appears as a regular space. which produces which though? 16:09, 18 August 2016 (UTC) — Preceding unsigned comment added by ....SandwitchHawk.... (talk • contribs)

to even further clarify, i also dont know what the hell unicode is in relation to how many encoding are displayed simultaneously and which one is which ....SandwitchHawk.... (talk) 16:13, 18 August 2016 (UTC)

I have looked though the article and it appears that after the examples of code were removed from the lead section in a recent edit, there is no example code to create a targeted redirect. Could someone please fix this? Thanks. --FactualCollector7d1 (talk) 02:15, 27 August 2016 (UTC)

I added a code example into the targeted redirects section, that should fix it. Does that make sense? Ivanvector 🍁 (talk) 21:27, 29 August 2016 (UTC)

WP:RSECT says that we should put a "linked from" comment in the targets of redirects. This is quite reasonable when linking to section title because section titles often change. But is the comment really necessary when the target is an anchor? The whole idea of the comment is so that editors don't change the name. The whole idea of anchors is that the name never changes. Surely an unchanging anchor cancels the need for piles and piles of comments in articles about incoming links.  Stepho  talk  07:44, 4 October 2016 (UTC)

A proposal to expand the criteria for speedy deletion to include redirects with specific disambiguation errors has been made at Wikipedia talk:Criteria for speedy deletion#Redirects with specific disambiguation errors. Interested editors are welcome. Thank you. — Godsy ^(TALK_CONT) 18:25, 13 October 2016 (UTC)

There is a proposal regarding redirects left from moving accepted drafts to article space being discussed at the Village Pump. If you are interested in participating in the discussion, please see Wikipedia:Village pump (proposals)#Draft Namespace Redirects. Cheers! Ivanvector (^Talk/_Edits) 14:08, 3 November 2016 (UTC)

An editor (me) has opened a discussion on modifying the criterion for deletion of implausible error redirects as it pertains to redirects from page moves. If you would like to comment on the proposal, please see the discussion. Thanks. Ivanvector (^Talk/_Edits) 20:47, 9 November 2016 (UTC)

@Billinghurst: In this edit, you commented out the link to Rdcheck. The link works fine, though it requires acknowledgement that you're leaving the WikiMedia Realm. It redirects right to the updated Rdcheck tool. Is there another reason for hiding the link? — Gorthian (talk) 05:18, 13 November 2016 (UTC)

Thanks Gorthian. I have tried so many tools: links and the redirects, that are broken. I have updated this from the old tools: pointing to the long dead toolserver to the direct toollabs:. — billinghurst sDrewth 05:27, 13 November 2016 (UTC)

Oh, good, thank you. I didn't know how to make that link. — Gorthian (talk) 05:33, 13 November 2016 (UTC)