1\. - 3. are all listed by Special:DoubleRedirects. They are remaining after the redirect bot cannot solve the problem.
4\. Interwiki redirects normally are fixed be interwiki bots except there is a \_\_STATICREDIRECT\_\_ in the redirect page.

rejected. I do not see any sense for a list duplication of Special:DoubleRedirects

• assigned_to: nobody --> xqt
• status: open --> closed

How is keeping track of problems bots are unable to fix a duplication of Special:DoubleRedirect's?

You asked me to file this bug request after I explained the problem I was having to you.

• status: closed --> open

They remain in Special:DoubleRedirects and must be fixed by hand or deleted by admins. It is easy to distinguish between multiple redirects and redirect loops and there is no need to explain it outside.

It isn't easy to distinguish they just appear like redirects bot can fix. I want to have the option in the code to log that and post this to the village pump for local communities attention.

It is very difficult for me to do that by hand on 700 wikis of which most don't even need my attention.

There are several bot who work on double redirects several time a day. The remaining items might be redirect loops or self redirects. e.g.

Foo --> Foo --> Foo
are always self loops

Foo --> Bar --> Foo
Bar --> Foo --> Bar
are always redirect loops

is it difficult?

When you are plowing through 700 wikis even simple tasks become difficult. A compiled report would let me know which wikis to notify that human intervention is necessarily on which pages which can denote the type of intervention necessary. The prepared report could be language specific so es.Wikipedia would get a report in Spanish, de.Wikipedia would get a report in German, etc.

Protected redirects are a problem particularly as they appear like stuff bots can fix but they can't because bots are unable to edit protected pages. This is not one of your examples. Special:Doubleredirects makes no distinction for this type of problem.

Redirect loops may be more than 2 pages. Among 200 entries such a thing could be difficult to spot.

Also while how to deal with redirect loops is obvious to you and me, admins in local communities are often more than uneasy in dealing with this issue they are not familiar with.

If there is nobody who can deal with these special pages, there is no reason to post it again on the village pumb. I guess a better way is to solve the remaining problems if possible. This means for redirect loops and self links:
\- check whether there is any possibility to solve the redirect link to a new page
\- otherwise tag it for speedy deletion.
I worked on that and the code is ready and I did som test edits in past. I guess I'll commit it in autumn into rewrite.

example of the current working copy working:
>>> USB-on-the-go <<<
Links to: \[\[USB-on-the-go\]\].
Warning: Redirect target \[\[USB-on-the-go\]\] forms a redirect loop.

The special page does not tell the user the type of problem that exists. It does not denote that bots cannot fix them. I just want to be able to log the problems the bot already displays on the cmd page so that I can review it and point issues on the village pump. It takes me weeks of discussion and nagging sysops to get them to fix the issues even on wikis like en.wikipedia. Why are you opposing this?

Local communities do not want automatic speedy deletion tags. I do not want to manually check all 700 wikis which are almost entirely in languages I cannot even read.

If there are any remaining items in the special page, this means the bot cannot fix them. You may create separated logfiles for each language and tag it to the village pump or elsewhere. You may use pagefromfile.py to tag it. Anyway I do not see the sense. If people do not process the special page what is your hope doing this by a another message to the community. And in general the implementation of such a message must reflect that some pages are already tagged by the previous run or previous bot. I guess it is easier to open a bugzila bug to enable some more descriptions about the items \(locked pages, redirect loops\). And at last: fell free to submitt a patch - we will see.

Sure. This would be ideal for me as well. However my proposal to prevent the creation of self redirects didn't even fly: https://bugzilla.wikimedia.org/show\_bug.cgi?id=34932

redirect.py wouldn't be needed if mediawiki was able to distinguish double redirect problems. I have been told that this is too costly which is why I do not expect a resolution on the mediawiki end.

Local communities are willing to resolve them if they know what the problem is and that bots cannot fix it. I want to periodically report to them.

mediawiki is \(\!\) already able to distinguish double redirect problems. This depends only by a config variable. This is not true for redirect loops where a solution is comming and supports bot users to fix it.

Do you have any sample or threat where peoble needs additional informations about broken or double redirects to fix them?