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.

@Tgr Doesn't seem like addTemporaryUserRights works, perhaps due to the different scope?

A very cheap way to do it, which I think is kinda like the last option @Tgr suggested, is to chuck in

$user = User::newFromName("ObscureUsernameCheckUserLog");
if ( $user->getId() !== 0 ) {
	$context->setUser($user);
}

I've picked this up where @Cenarium left off, rebased into current master and updated some small things to make it work: https://gerrit.wikimedia.org/r/316410/

This is also broken. rev_timestamp is a blob, not an integer, so this query also fails to return results. Tested in SQL console with and without encapsulating it in quotations, and the former returned results, the latter (as in code) did not, so I believe that is also related to this.

@DannyS712 No - I get "No results". The filter is public and I've enabled all the permissions for my role.