@TheDJ do you know what this task is blocked on? (afaics your patch contains all the code needed to make this happen?)

Specifically in the case of T302047, I would prefer that active contributors on primarily single Wikipedias not be deploying those patches. For example, and without getting into the details of the mitigation here, I think English Wikipedia has certain philosophical beliefs that are not shared throughout the Wikimedia projects, and while sometimes restrictions will have to be implemented to ensure for service/reliability reasons, they should be proportionate and the minimum necessary to deal with the threat. At times the IRC discussion involved suggestion of options that were either too extreme, too soon, or not the minimum necessary to mitigate the emergency issue. I think having detached deployers (IIRC one of which said they were mostly a backend person and not focused on the onwiki-side) who looked at the proposals and offered the feeling of space for anyone to raise objections before deployment, operating quickly but cautiously, was the best approach in that situation.

Possibly related: https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard##WPWP_is_back

If the technical implementation in the patch works then I think it should be merged. It's up to local communities (and external projects) to grant this right or not. There's not a particularly good reason for why it shouldn't be technically possible for them to decide though.

Why is this still stalled, even though a patch exists?

In T240889#7113694, @AlexisJazz wrote:

In T240889#7108934, @MMiller_WMF wrote:

Hi @AlexisJazz -- no, I'm not suggesting any sort of vote or judgment around IP editing. That's a much bigger and more complicated question than I think we're talking about here.

Personally I'd support it. I'm now dealing with an IP editor who changes IP every day. So if I leave them a message, they won't see it because their IP often changes between me leaving the message and them visiting Wikipedia. I need to tell them about using reliable sources, but can't. Also I could stop worrying about accidentally leaking my own IP. (it HAS happened)

So now we have sysops blocking community consensus in the name of the WMF (and they still are, ptwiki created ugly workarounds to make IP-editing more difficult to override the sysops) while the WMF says "Deciding the amount of resourcing we provide for the IP editing experience is always a challenge". Finding resources for it is a challenge but if a community wants to get rid of it they get told it's "not gonna happen". You either find the resources (in which case I suggest using the salary of two executive management members) or you respect the wishes of communities who want to disable IP-editing. You can't have your cake and eat it too.

The issue starts because, when stewards do that, local 'crats would say that stewards are overstepping their boundary, and that is why it'd the removal is also being removed from 'crats.

Well, I said this at enwiki BN, so will repeat here:

In T282624#7081573, @Minorax wrote:

In T282624#7081570, @Minorax wrote:

Totally agree with SilkTork, bureaucrats should have access to Special:VerifyOATHForUser. While still unpopular, I believe temporarily de-crating a user until they enroll in 2FA is a better solution than removing one of their main scope/job quoting that crats don't need to have 2FA enabled. Correct me if I'm wrong, I believe that this was done when IA & CNA were introduced back in 2018.

Seems that letting crats have access to that special page is more dangerous as I thought it would be

It would've been better to post a consultation on meta and advertise it via mass messaging to the local communities and let it run for a few weeks. That way you get the ability to 'discuss' and evade the criticism of possible fiat by the WMF. The world would not end if crats get to flag IAs for another few weeks. At least from a PR standpoint (no pun intended) it'd have been a good idea to discuss it first...

The use case is https://en.wikipedia.org/wiki/Wikipedia:Bots/Requests_for_approval/ProcBot_8. No API endpoints exist for editing abusefilters. So I decided to mimic the HTTP requests, but that approach can turn up a few caveats and is slightly less maintainable. I cooked up a web scraping approach using Selenium as well and that might work better. But to run it'll need a browser with headless and modern JS support (both Chrome and Firefox work, so I mentioned those two; either will work).

In T278838#6974614, @GeneralNotability wrote:

In T278838#6972791, @Valereee wrote:

I tried to fix a typo and a notice came up that said I had been blocked from editing. There was no explanation why, nor any indication of how I could find out why. How can I find out? This has happened before, and I think it happens when I'm not using WiFi.

Probably a big rangeblock on your carrier, @Valereee ...but it's hard to tell the actual block reason, now, isn't it!

Okay, I'm mildly misunderstanding how the FlaggedRevs one works. Looks like it's part of /frontend/FlaggedRevsXML.php line #364 (function logDetailsToggle()).

@matmarex ping again on the above. Alternatively, could we provide the log entry as a param to the template rather than forcefully including it via code, so a local project could collapse/trim it if they want (such as on the Pending Changes messages, see https://en.wikipedia.org/w/index.php?title=Inner_Mongolia&action=edit for example.

Some indicators have more value than others. The protected indicators are semi-valuable (but less-so on mobile, I suppose - either you can edit it or you can't, and that's indicated by the lock on the pencil icon). The move indicators are totally useless. The featured content indicators are useful, imo. Generally, there's a higher degree of quality to GAs/FAs (yes yes, I know, the disclaimers and all, but it's generally true as a rule). Good articles are pretty much a basic peer review, and quite different to featured articles which go a lot deeper. For example, on enwiki GAs require the coverage in the article to be broad, and FAs comprehensive. How many readers actually know this I don't know, but once you know this I think it helps to know that when reading the article.

So... what's going on with this task (and FlaggedRevs in general)?

Also see T275118

Also see: T263943 (preceding task)

Note @ToBeFree's link is regarding the iOS app (not Android as in this ticket). But this is a problematic issue both ways - communicating with editors is very difficult without notifications.

@matmarex @ppelberg the patch I released was somewhat tangential to what I intended this issue to be (it's an improvement, but not a 'fix' in my eyes). I'd still like to focus on hiding these details (at least the semi-protection ones) in that message entirely, if it's something I can swing by whoever needs to sign off on this. It's really irritating for me to see that regular long log dump on every other page, most of which I just can't see a use for. On pages without an actual notice, it pops up anyway (when in its absence nothing would pop-up) and slightly throws one off. Just doesn't feel like it belongs.

@matmarex got around to the ordering, at least, in above patch. Could you see if it's all good, when you have time?

May be of interest for enwiki: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Move_good/featured_article_topicons_next_to_article_name

Saw this posted today and it makes me think, it could just be at the end of the text without alignment without much trouble?

Although if you're not interested in this, I'll probably submit a patch myself.

@JTannerWMF would editing be okay with / approve a volunteer patch for this? Either an option to disable this (from all editors), or disabling them entirely, one or the other?

@TheDJ curious why the patch was abandoned? Seems like it'd technically work?

That said, I think that adding in remaining space on the right side of the title (or adding a newline) is the best solution and it can be managed in the same way.

There are cases when bot reverts should be notified. The most obvious one to me is ClueBot, https://en.wikipedia.org/wiki/Special:Contributions/ClueBot_NG. Edits are marked as minor, not sure if they're marked with bot too. Second, sometimes bots edit articles and the contributors don't want that bot edit. Many bots will edit again if the bot is reverted (they're not that smart), so notifying editors that a bot manually reverted them would seem a good idea. Such bots (at least on the English Wikipedia) will be flagged as bots, and typically mark their edits with bot: true as well, so using the fact of whether or not the particular edit by a flagged bot was also marked as a bot edit won't work.

@matmarex imo it's pretty useless, but maybe removing it from all editors may prove a bit more work (in terms of process)?

@matmarex whoops, I didn't mean mobile. I'm getting my tasks mixed up (as I've something similar to the opposite for mobile). Sorry, will update to clear it up.

@Tacsipacsi to be completely frank, and just my opinion, but wikis don't exactly have the best idea of "what's important" from a UI perspective. Move protection indicators, for example, are utterly useless. Even 99% of editors don't wish to move the page, never mind readers. They're in place to stop the odd users moving articles, yet an icon is shown to everyone. On a smaller scale, especially for mobile, this applies for page protection too -- most people just read not write on mobile, and showing colourful locks is not particularly helpful, especially on a mobile view where they'd stand out a lot more. When you start looking at talk notices and editnotices the point becomes more obvious imo. One 'unintended' advantage of the software limitations of the mobile style is that it saves the mobile UI from becoming a cluttered mess. Quality assessment indicators are neat, and give a useful indication for readers also, though.

@TheDJ regarding "were repeatedly pointed at how useless many of these banners were", do you have links to a few past discussions by any chance?

I do think that stuff like pp-protected should be hidden on mobiles. We only want to show indicators like good-article / featured-article. The rest is kinda bloat.

on wiki edit notices can be extremely verbose

@Huji Yeah, I can submit the patches (one to add it into AF before the call, then another to revert the wmf-config patch). It'll probably be a week till I can get around to it, though. If you can get around to them sooner, it's fine with me for you to submit the patches :)

Sure, but there's a bit of a difference in having to write your DB credentials (something the software could never possibly auto determine), and having to add in a config variable for the software to work as we intended it to.

Shouldn't those hypotheticals also be hardcoded in? My reasoning is that the point of configuration is for users to change how the software behaves. This is making adding a configuration variable a requirement for functionality to work as intended. There's no developer intention, or valid purpose, for this data to be purged from CU logs. So we're kinda just adding an extra hoop, and most non-Wikipedia users who run into this probably shouldn't have to jump into some obscure part of the doc to realise that they have to add a compulsory param. We can keep the config param too, I suppose, for future additions, I just think this particular param should also be hardcoded in.

I believe this added param still needs to be documented at https://www.mediawiki.org/wiki/Extension:CheckUser. I wonder if a note should be added to https://www.mediawiki.org/wiki/Extension:AbuseFilter as well, since it appears to be the sole (?) culprit requiring this.

@Huji do you still plan to schedule the deploy for the 6th?

@Majavah thanks for the heads up. I was under the impression that it had to be +1'd first (aware the +2 is during deploy), but if that isn't required I'll go again and schedule.

(Just realised I'm too late): In support of the tags idea which would also cleanly allow for multiple watchlists (T3492) with the method described in T182297. Tags would be quite a powerful concept, and expiry times could've been an 'action' based on tags.

Having taken a quick look at this, seems to be due to the $item->canView() checks failing (eg at SpecialRevisionDelete::showForm, line 420). That function is in RevDelRevisionItem, line 81:

In T256758#6271128, @Proc wrote:

Created a bug on WebKit's Bugzilla for this as well.

In T256758#6270949, @Xaosflux wrote:

This fix really should be on the browser side, phone numbers are normally written with a hyphen ("-", 0x2D) while in articles such as the example above with date ranges we normally use the en-dash ("–", 0x2013). Apple probably shouldn't be doing phone number translations on en dashes.

@Jdforrester-WMF @Aklapper if the functionality is indeed undesirable I'm not sure if it matters whether Apple fix this on their end (which, ultimately, I'd think any 'fix' would require removal of the feature, since it's hard to determine whether 900-1200 is a phone number or a year) or if MediaWiki does just for its software using the meta tag. (I believe this tag is only recognised by Safari for these purposes, but I could be wrong). Of course, links can still be formatted as tel if they're explicitly formatted as such, and via the use of a template it'd be neater than the a tag everywhere.