If the endpoint handler removed trailing slashes, there would be no need to obsolete the endpoints (though they could still be deprecated for clarity), and old clients would still work. There would be no need for individual documentation or routing, just as in the current proposal.

• Above it is suggested that spam/advertising are quite likely to be copyvios. If the spammer/advertiser is an agent of the copyright holder, they have arguably relaxed the copyright by publishing it with a CC license. Perhaps more to the point the reason for the revert is not copyvio.
• I'm not sure that we should distinguish between deletions of revisions and reverts, since an effective revert is still required - except where a page is deleted (in which case it should probably be blanked anyway before deletion, as a belt-and-braces measure).

"Supposing category:A redirects to category:B.
Would it be feasible to automatically move all articles placed in cat:A into cat:B instead?
Alternatively, would it be possible to create a Specialpage that lists all categories that are redirects, so that a bot can do the moving?"

I now see an error message (https://incubator.wikimedia.org/wiki/Template_talk:Test_wiki) -> https://incubator.wikimedia.org/w/index.php?title=Template_talk:Test_wiki/639-3&action=edit.

Does this need additional tags?

Isn't this just returning the responsibility for case-folding to the programmer? (I wonder if there should be a Unicode character "Upper Case Dotless I"...)

Notes:

1. Proper versioning means being prepared to do "complex migrations" as in the example the description mentions. We should deal with our technical debt neither "just leaving mistakes in forever" nor deleting data to hide the past.
2. The original reason for imposing a limit has never been discussed with the community. The change https://www.mediawiki.org/w/index.php?title=Topic:S2gux2za46y9zqsv&topic_showPostId=v3aoduag8wpvgroy#flow-post-v3aoduag8wpvgroy was put live some 10 years ago to address a "production bottleneck". No engagement has occurred to discuss what the "production bottleneck" is or was. However it is quite possible that a simple change to a SQL query somewhere would have obviated the whole enterprise. We should look into this before replacing one deletion system with another, however superior. For example it may be possible that simply having an "archive" bit set for everything over 12 months would resolve the production bottleneck. It may be that the bottleneck is in code that has since been deleted, or that another change has rendered in no longer a bottleneck.

What is "unsemantic" about these class names? What new names are proposed? How will new names improve understandability? How do we know the new names are going to be more understandable? Who will they be more understandable to? Will there be any benefits beyond understandability?

Note the monitoring of rate limits mentioned above has been shifted to the Grafana ticket https://phabricator.wikimedia.org/T357763
The relevant graph can be seen at https://grafana.wikimedia.org/d/e293b3fd-032f-4915-a6c0-72b6062d66b5/temporary-accounts?orgId=1&viewPanel=11

I think one of the issues here is that we want are trying to distinguish between various types of editing activity. For example if a user re-orders the sections on a talk page we don't want to issue any new notifications. It might be best to use the diff algorithm, which goes some considerable way to understanding edits in terms of what is new content.

Is there a definition of "banal copy"?

Lets fix this. This ticket has been used as an excuse to remove the functionality form the English Wikipedia among other places, riding roughshod over the wishes of the community. That is assuming other scripts don't just insert "ISBN" - which I have seen very often.

In T145604#9804569, @Jonesey95 wrote:

In T145604#9804125, @Rich_Farmbrough wrote:

Why, since the comments on the RFC were overwhelmingly against this proposal, was it implemented?

It was not, AFAIK. See the part of https://www.mediawiki.org/wiki/Requests_for_comment/Future_of_magic_links#Proposal where it says "Update: this part was controversial, and will be re-evaluated based on the response to disabling by default."

Magic links were made enable-able on a per-wiki basis instead of a built-in feature of the core code that could not be turned off or on.

The English Wikipedia overwhelmingly decided to turn them off: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=772133164#Future_of_magic_links

Yes, that is correct. See also T227853.

It's pretty important that Anomie's stuff works. It would be great if it was considered a priority to help resolve this issue.

Why, since the comments on the RFC were overwhelmingly against this proposal, was it implemented?

It might be beneficial to consider blake2 as this runs much faster than SHA256.

OK I had the same issue. The config file was:

Wouldn't the best fix be to make the processes scalable? I'm amazed that 100 million rows here or there cause a problem

"Waiting to see if this becomes a widespread issue." Meanwhile data is being irretrievably lost,.

Thanks for fixing.

Not sure why this needs triage now. It's a long standing broken part of the system, which should have been fixed a long time ago. If the foundation can't fix it in 14 years, and with, I suppose, about $1bn to spent, I despair of having anythung useful done. Certainly lowering the priority won't help, and raising it seems unlikely to either.

I

ndex: SiteInfo.cs
===================================================================
@@ -252,7 +252,7 @@
             // web lookup if not in cache
             if (string.IsNullOrEmpty(catCollationInfo))
             {
-                catCollationInfo = Tools.GetHTML(@"https://noc.wikimedia.org/conf/InitialiseSettings.php.txt");
+                catCollationInfo = Tools.GetHTML(@"https://noc.wikimedia.org/conf/VariantSettings.php.txt");

There are a number of points worth making here, though they do not impact on the base idea behind the bug, indeed one is makes it more important.

Just a note that this impacts potential extensions that rely on this type of functionality.

We will be wanting to insert something like

To be consistent with the history view, the number should be displayed before the edit summary of the right hand edit. This may be misleading in that it appears to assign the change to the last edit.

Question: The diff view from history is a different use case to the diff view for "show changes". It is also different from a diff generated from two page version numbers which are not necessarily of the same page. Will this patch need to distinguish these cases? If the numerical value is stored in the database, then the history version may be simple, for adjacent versions. For non-adjacent versions it will still need calculating.

Is this total destruction of a historic set of documents?

There is also the possibility that it is something else loading from bits, perhaps. There seems to be a metric tonne of css, js and other stuff in there.

Simple way is to re-instate magic links.

I agree with SV above. This is a major (and somewhat foolish) change. It should not be imposed by a technocracy.

Great work everyone (especially Ryan!).
Simple is good.
I have changed hidden filter 12 on en:wiki so that it will work with either version of ccnorm, after the Mediawiki change it can have the code for old version removed.
This approach means that we get no gap where filters are inactive, and hence no narrow window for implementing the changes, nor any rush after the Mediawiki change.
It also means that if we have to revert the Mediawiki change within a short time, the rules should still work.

The correct solution for this problem is clear if we separate the concept of Wikipedia articles from Wikidata items.

Here is a plan:

And here is some MIT licensed glue to both POSIX and PCRE libraries. http://rrthomas.github.io/lrexlib/

This should be fixed. Of course breaking reg-exes exist, but we face the same problem as we did when we tried to deny template developers parser functions on the grounds that they were idiots and would break the whole wiki - namely that someone will write Module:RegEx.

There are privacy issues here. I have initiated a discussion at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28policy%29#Privacy_and_dark_traffic

As the latest person to get bitten by this bug, can I press for some progress. If the category suggested by Tim in six years ago, and Mr Stradivarius one year ago can be implemented, then we can at least get some idea of the magnitude of the misfeature use. Conversely if they can't let us find another way forward.

This is a real nightmare.

Ok thanks.

Thanks

@Aklapper - best to ping me via my en:wp talk page

There has to be concern that a recursive check like this could seriously degrade the privacy of users. For example suppose that I am a trusted user - something I am never sure about - and I come up as having shared an IP with a vandal. A manual checkuser would stop there, and perhaps confirm that the IP usage was widely disparate in time if it was an dynamic IP, or was a communal hotspot or something, but a recursive one would identify all the IPs I had edited from, and all the editors who had edited from those IPs, etc.. I know certain editors who do not want their attendance at meet-ups shared with non-attendees, and it would certainly not be a good thing to have these associations seen by some who have Checkuser power, and doubtless archived on the Checkuser wiki for all eternity.

I like the tag "Huggle" since it's a proper noun. WPCleaner does and AWB would also start with capitals. Keep lower case for things like "generic tool".

Confirm this is almost ubiquitous. And possibly linked to https://phabricator.wikimedia.org/T101224

There is a throttle setting that is overridden of WP:EN, specifically to allow the use of mass rollback/undo. Perhaps this same mechanism could be applied here.

We could drive this of edit-filters fairly easily,if that's what you mean. The existing solution should be blindingly fast, and is easy to understand Edit filters would have the benefit of simplifying the overall scenario, and of providing a warning log that could be useful in forestalling abuse.

Given there are some issues about the change-set proposed by Platonides (for which thanks), can we resolve this bug by utilising the fallback mechanism Krinkle mentions to "Restricted-use media list"?

I strongly disagree with this. There is no purpose to be served other than vindictiveness in denying locked users the ability to receive email.

It's worth noting that one often comes to Wikipedia with an unknown term, where there is uncertainty in both the language and meaning. This use case would not be helped very much by this solution, though other cases might.