Wed, Aug 14
Jun 25 2019
May 10 2019
Mar 21 2019
See also T13739, "Inverse selection for [[Special:Log]]".
Feb 26 2019
Feb 2 2019
Jul 1 2018
Yeah - on enwp we can use RevDel to remove the visible traces of vandalism, but that's obviously not an option here.
Once the reversions are done, will it be possible to get the traces of this attack wiped? TBH it seems to me like this matter would best be handled at DBA level.
Apr 27 2018
Apr 23 2018
Hi @Niharika, I edit the English Wikipedia, and my language setting is English. I got a security notification from the Spanish Wikipedia, in Spanish.
Apr 21 2018
To clarify here: their preferences where? On their home wiki? Or the one they've never used, where a security alert has been generated?
Apr 20 2018
So you think that a security notification should potentially be sent to users in a language that they don't understand - possibly even in an alphabet that they can't read. That makes no sense whatsoever. If one user throws the message in the trash without reading it because they can't, then it has failed to do its job.
Mar 12 2018
Jan 20 2018
+1000 for this cogently-put argument.
Dec 28 2017
@He7d3r - you're right, sorry; looks like I glossed over that part. Done.
Dec 24 2017
agree that it's probably a good idea to strike vandal accounts (does action=credits even respect RevlDel?)
Nov 9 2017
May 7 2017
Jan 7 2017
See also T23175, "Add log excerpts to revdeleted diffs".
Magic linking is going away - see T145604#2925139. ISMN links would need to be implemented using templates.
Nov 15 2016
Linking to a comment on the EnWP village pump from a user who's having trouble logging in here.
Nov 4 2016
Does this mean that T96301 has been resolved?
Oct 30 2016
Oct 18 2016
There could be, but I don't know of any, and we should build to existing use cases, not hypothetical future ones.
Oct 14 2016
A good point. The maximum should always be the current year.
Sep 30 2016
Jul 20 2016
Jul 9 2016
Jul 4 2016
You may see it as being patronizing, but this is basic facts.
Jul 2 2016
@kaldari - don't get me wrong, I also want it turned off for exactly the same reasons! I just believe that the change should be made in a way that doesn't risk inconveniencing hypothetical users reliant on a long-established feature. It's hard to think of a feature that's been around longer; this predates MediaWiki.
I agree with Danny that this task is a duplicate of T47942. That task calls for magic linking to become an optional feature; there may be some people who are not in a position to use bots or gadgets to replace the functionality if it's removed entirely, and we should consider them.
May 26 2016
Copied comment from over there: adding as a blocked task because if the magic linking code is going to be addressed it should be done properly, rather than a hacky workaround in the notifications code.
Adding that as a blocking task because if the magic linking code is going to be addressed it should be done properly, rather than a hacky workaround in the notifications code.
@Quiddity - sincere apologies. I was reading on my phone and completely misinterpreted the diff. All good.
I agree with the sentiment that pages in Draft: shouldn't get a "publish" button. If anything, an action somewhere in the UI labelled "publish" that is actually "move this draft to mainspace" would be a useful feature. But that's obviously outside the scope of this task, and as noted Draft: pages aren't effectively off the public web anyhow.