In T307860#7912248, @AndyRussG wrote:

@AlexisJazz, @Tacsipacsi thanks so much for looking at this!

Quick explanation:

When testing CentralNotice banners on the mobile skin using a desktop device, you may need to tell CentralNotice which device category to pretend you're on.

If you don't, the device will be categorized as "Unknown", and if a banner doesn't target "Unknown" devices, it won't show.

Here are some URLs that do work on the beta cluster on a desktop device:

• https://en.wikipedia.beta.wmflabs.org/wiki/Bert?useskin=minerva&device=android
• https://en.m.wikipedia.beta.wmflabs.org/wiki/Bert?device=android

CentralNotice uses really simple device detection logic: if you're not on the Minerva skin, you're a desktop device, and if not, you're one of the other devices.

Thanks again!! :)

In T307851#7912025, @Aklapper wrote:

I do not want to use the mobile domain

Why? What are specific reasons that are only related to the domain and not related to any skin being chosen?

A link was provided. You have a browser, you can read, you should be able to figure this out.

In T307851#7911817, @Aklapper wrote:

I don't yet understand the underlying problem to solve. Could you provide an actual use case please and specific devices related to that use case? Thanks.

• I do not want to use Minerva on my laptop!!!!!!
• I do not want to use Vector on my phone!!!!!!!
• I do not want to open up Special:Preferences every time I visit Wikipedia on a device different from the last device I used to visit Wikipedia!!!!!!
• I do not want to append ?useskin=minerva on every page while using my phone!!!!!
• I do not want to create an alternative account for my phone!!!!!!
• I do not want to use the mobile domain which has been established to be worthless for anything but very basic reading!

As the description was overwritten: it didn't break instantly and maybe it was never strictly down, just too slow to work. For me it was extremely slow for a few minutes or so first (taking 20s to load a page) until finally I saw "upstream connect error or disconnect/reset before headers. reset reason: overflow".

In T299629#7899894, @sbassett wrote:

In T299629#7898178, @AlexisJazz wrote:

I hadn't heard of StopForumSpam before, can I see the logs for betacluster anywhere?

If you have access to https://beta-logs.wmcloud.org/ or /srv/mw-log on the beta cluster servers, they're in channel:StopForumSpam. I don't believe they're publicly accessible in any way though.

I think (but to be frank I have no stats to back up what I say) you need something to stop the very dumbest bots. Not much. On the server side, I suspect you could check if the user has completely filled out the account creation form in less than 3 seconds. If they did they are either not human or didn't read what they were submitting.

There's a few public grafana panels for this, which might be helpful:

1. captcha failure rates - https://grafana.wikimedia.org/d/000000370/captcha-failure-rates?orgId=1
2. auth metrics - https://grafana.wikimedia.org/d/000000004/authentication-metrics?orgId=1

There's probably something to the "not very smart bots" hypothesis in that there are quite a bit more captchas displayed than captchas which are, eventually, correctly or incorrectly solved. Though with just numbers, it's difficult to discern the ratio of "not very smart bots" and frustrated human users. Surely there is a mix of both, unfortunately, which was one of the motivations for running this experiment - to better determine what that might be.

In T305216#7899173, @hashar wrote:

I have looked at the new errors in the log and it is quiet. There are a very few showing up which are already tracked and with a low frequency, thus it looks good. There are three blocker tasks still.

In T307311#7898304, @Aklapper wrote:

On a cold cache that URL every time loaded in less than 3 seconds here. Cannot reproduce a problem.

In T306477#7896625, @EBernhardson wrote:

I'd assume "matching section" would refer to the section in which the search terms were found, not just section titles in which the search terms were found.

Matching here literally means the text of the string matches the text of the piece of content (the section headings). The content is separated into independant conceptual chunks, such as the headings, the categories, content, etc. Throughout search (not just this one feature) there is no concept of textual content being a part of a section. The sections are simply a separate list of strings to match against.

The description for "sectiontitle" is "Adds the title of the matching section." while the description for "sectionsnippet" is "Adds a parsed snippet of the matching section title." Wouldn't "Adds the title/a parsed snippet of the first section title that matches a search term" be more accurate?

In T306211#7897565, @kostajh wrote:

In T306211#7894785, @AlexisJazz wrote:

In T306211#7869547, @mewoph wrote:

Hi @AlexisJazz thanks for filing this! I've moved the task for our team to discuss.

Thank you! Where will this discussion take place, can I follow it?

As I'm aiming to get my userscript released soon, I've implemented a kind of echo-emulation into it. Simply put it stores notifications in a userjs- preference and tacks them onto .mw-echo-ui-notificationsListWidget. It has endless limitations and will probably not be much fun to maintain, but I needed the functionality. I'm looking forward to being able to echo oneself so I can dump that ~18K of rubbish code from my script.

We usually discuss tasks in our internal team chat, then write the conclusion here. The most likely outcome is that we won't have time to work on this, as this isn't something related to our team's roadmap. I'm tagging the Security-Team in case they have thoughts about the idea. Basically this would mean that any userscript/gadget could issue a notification type with arbitrary text/action links, right? That is a departure from what we currently have, with notification types defined in code and going through code review, so I imagine the security team would want to be consulted about this proposal.

In T299629#7897646, @sbassett wrote:

In T299629#7869964, @AlexisJazz wrote:

My thought is you add some form of negative captcha as with absolutely nothing this is almost guaranteed to fail. We set the anti-spam abuse filters to log-only which may help in analyzing the results and to prevent spambot IPs from being blocked. Disable the captcha. And see what amount of spam we get.

The problem with negative captchas though, is that they can catch a lot of accessibility tools like screen readers, etc. and falsely trap them. Really, that's just the crux overall with any kind of Turing test like captcha - the common tools many folks rely upon for accessibility and anonymity are the same tools malicious actors also use to carry out their nefarious efforts. If wholesale disabling FancyCaptcha on beta (or anywhere else) just seems like a bad idea to those in the community who are closest to mitigating spam/vandalism/harassment, then it might make sense to abandon this experiment, as FancyCaptcha would clearly be doing some good.

Another data point to consider is that, with StopForumSpam now enforcing on the beta cluster (T304111), we've seen 65,438 blocks and 20,163 exemptions over the last 30 days. That seems like a lot for something like beta cluster, from just one deny list, within a test environment that likely doesn't see near the potential abuse that enwiki and other large projects do.

In T306772#7898026, @Aklapper wrote:

I had no idea that text is added by gadgets. Thanks for the clarification!
Still proposing though to decline this corner case...

In T306477#7896517, @EBernhardson wrote:

To get a section link the name of the section has to have at least a one word overlap with the search query. A section link is additionally only identified when neither the article title or category list match the search terms. Critically it also doesn't matter which section title matches, having a section title close or far away from the other search terms is not taken into account.

Adding barnstar to the query, matching an expected section title, gives a section link as expected: https://commons.wikimedia.org/w/api.php?action=query&format=json&formatversion=2&list=search&srsearch=barnstar%20%22I%20found%20this%20rare%20and%20important%20surviving%20copy%20of%20the%20Ten%20Hour%20Day1835%22&srprop=size|sectiontitle&srnamespace=*&srlimit=10

Everything must be spelled out..

In T306211#7869547, @mewoph wrote:

Hi @AlexisJazz thanks for filing this! I've moved the task for our team to discuss.

It's working again but I'm not sure why. I opened the language selector, selected "Display settings", picked English and pressed "Apply settings". Unlike picking from "Suggested languages" it worked that time. And afterwards the "Suggested languages" also worked again.

And T307294.

In T68606#7625182, @Tgr wrote:

In T68606#7624808, @Dylsss wrote:

Just to clarify, that isn't correct, policy wise, it is a valid and usable template. And technically it has the metadata to be picked up by CommonsMetadata, the issue is T89692, where CommonsMetadata appears to be prioritizing the least restrictive terms.

Technically the image is marked up as being PD and attribution-only. When a file has multiple licenses, it is valid to pick one and show only that, and it makes sense to use the least restrictive one for that as it gives the user the most options.

But as you've seen this isn't true. Just pick the least permissive license to be safe. It's better to tell a re-user they must attribute when they actually don't rather than the other way around.

Please check T306758 and (unrelated) T307173. They may or may not be limited to beta cluster.

WTF! After viewing the page, the "updated since your last visit" for everything since 14 April went away.

This is really strange:
https://commons.wikimedia.beta.wmflabs.org/w/index.php?title=File:Test_upload_header_3_$100_bill8.svg&diff=278109&oldid=278106
Summary for move from 21:50:
AJ moved page File:Test upload header 3 0 bill6.svg to File:Test upload header 3 $100 bill7.svg without leaving a redirect: test money move

I agree that adding a link to the project page is a good idea.

In T307113#7888446, @sgrabarczuk wrote:

Yeah, right now, there's no easy way to find our project page or project talk page, which is becoming an issue, since more individuals and communities do/are going to have Vector 2022 as default.

If Vector 2022 was a beta feature, there would be Information and Discussion links provided, because that's the standard for beta features. So we need to find a workaround.

@TheDJ: I only just noticed T6845#7664178. GMTA I suppose.

In T306299#7862692, @matmarex wrote:

Since apparently no one noticed the problem other than you, it seems like we could just fix this.

Others probably noticed, but I bothered (and knew how to) file a task. I was actually looking for a way for my script to obtain page titles and section titles as cheap as possible (DOM queries tend to get expensive with many sections), so I tried extracting the section title from the tooltip so I wouldn't need to poke .mw-headline at all anymore. It was faster but caused problems.

In T306660#7878519, @alexhollender_WMF wrote:

@AlexisJazz collapsed sections is an option. can you expand on why you like it?

Changing priority per Urbanecm at duplicate task.

T306882 might be something. (if I'm at the wrong version again please copy this comment to somewhere else)

@kaldari

mw.util.addCSS('.tocnumber{display:none}')
for(toctextint=0;toctextint<$('.toctext').length;toctextint++){
	if ( $('.toctext')[toctextint].innerText.length > 80 ) {
		$('.toctext')[toctextint].innerText = $('.toctext')[toctextint].innerText.slice(0,70) + '..';
	}
}

In T306246#7878200, @Jdrewniak wrote:

From my reading of this ticket, it seems that transcluding {{MediaWiki:Bad image list}} into MediaWiki:Pageimages-denylist could be the easiest solution here, as @Ahecht suggests.

@AlexisJazz when you say MediaWiki:Pageimages-denylist just doesn't seem to work at all, do you mean that in the context of looking at: the new search results, with the new Vector 2022 skin, on betacommons? The reason for that may be that thumbnails for the new search are disabled on commons, and betacommons inherits that configuration. https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+/refs/heads/master/wmf-config/InitialiseSettings.php#7969

'wgVectorWvuiSearchOptions' => [
	'default' => [
		'showThumbnail' => true,
		'showDescription' => true,
	],
	'+frwiktionary' => [
		'showDescription' => false,
	],
	'officewiki' => [
		'showThumbnail' => false,
		'showDescription' => false,
	],
	'commonswiki' => [
		'showThumbnail' => false,
		'showDescription' => false,
	],
],

Outside of those wikis, the proposed solution should be visible on the new search. It can be tested elsewhere like beta-enwiki for example.

In T306772#7876217, @Aklapper wrote:

I'd say that anyone is free to enter gadget name instead of (gadget name) to solve this "problem". Proposing to decline.

In T306772#7876069, @Aklapper wrote:

When the first non-white space character is a (, the colon should be omitted.

No. Why?

In T306758#7875572, @Reedy wrote:

https://commons.wikimedia.beta.wmflabs.org/wiki/Special:Transcode_statistics

Looks like it definitely worked at somepoint.. But not sure if recently...

In T85838#7875279, @Thisisnotatest wrote:

In T85838#7875264, @AlexisJazz wrote:

In T85838#7875197, @Thisisnotatest wrote:

It's not necessary to loop a video. If someone wants to see the video again, they can replay it.

Except that makes little sense for the example as it's just 2 frames. Playing it once won't achieve any effect at all.

Oops! Totally valid point. That said, you could create 5 seconds worth of frames as a video. That would demonstrate the concept, and it would be under the site visitor's control and consent as to whether to play it or not.

There's still the issue of it potentially being seizure triggering. I acknowledge the linked .gif file carries more of a risk of triggering than the thumbnail does, because of the larger size, so probably the best path would be to link to a thumbnail then to the full size .gif, both links carrying trigger warnings, so there is full informed consent and knowledge of the risks.

If someone actually gets a seizure from viewing that gif, my guess is that they probably are not going to be in a position to scroll the page.

In T85838#7875197, @Thisisnotatest wrote:

In T85838#6532138, @AlexisJazz wrote:

Speaking as an offender, I used an animated GIF on frame rate control because:

• I don't know how to loop a video with TimedMediaHandler

It's not necessary to loop a video. If someone wants to see the video again, they can replay it.

Bawl can now collapse sections on articles as well. @alexhollender_WMF is there some sort of standard or known convention for when the chevron points up or down? I have the opposite of what you have. I felt it made more sense for the arrow to point at where the content is, not where it goes, but if this is contrary to convention (I can't think of any good examples to look up) I may have to flip my chevrons.

In T273473#7872624, @XanonymusX wrote:

Sounds reasonable. However, I feel like most of the reasons for using NOTOC or Compact TOC atm become obsolete once a TOC is permanently shown next to the content. For example, while having a traditional vertical TOC for an alphabetical list is not very helpful and looks terrible, with the new TOC it would make more sense than the compact horizontal one (which is not permanently visible and thus harder to navigate). I wonder whether the behaviour could be improved in that regard.

There is no "report spam" button here I think..

Request from - via deployment-cache-text06.deployment-prep.eqiad.wmflabs, ATS/8.0.8
Error: 502, Next Hop Connection Failed at 2022-04-22 02:23:20 GMT

Wasn't even looking for it, just came across it during one of my filemover rounds.

I vote that collapsed sections should at least be an option. You can add a button to collapse/uncollapse all.

In T306246#7864393, @Jdlrobson wrote:

Please also read the format https://www.mediawiki.org/wiki/Extension:PageImages#Configuration

You are mistaken. If you spot one rotten apple full of worms, the whole batch is fodder.

Yes but that's an editorial concern. A bot is not going to know which ones are inappropriate and which are not (and Wikipedia is not censored), thus a human needs to decide which articles have inappropriate page images and remove them on a case-by-case basis.

It is very simple: if the image is on MediaWiki:Bad_image_list it's not appropriate. No editorial concerns here. "Wikipedia is not censored" does not apply here, I'm not saying anything about article content. If you actually view the article about anal sex, you should see an illustration. But not when you are searching for something unrelated.

In T299629#7869346, @sbassett wrote:

In T299629#7859962, @AlexisJazz wrote:

What about beta cluster? We have spambots too.

We could potentially start there, though we'd still need real-world data on some of the larger projects as well.

In T306319#7863407, @Umherirrender wrote:

mw.Api is a helper/framework to make requests against api.php on wiki pages of MediaWiki wikis. To read action=help you can also visit Special:ApiSandbox on that wiki and use a gui to build up your query

It provides some solution for abstraction things of api.php like the multi-value separator linked in the task description (or handling of bool parameters). As mw.Api and api.php are two things, there should not linked together. When writing a bot in python or any other language it is not helpful to get a link to a javascript framwork, even it is build-in into MediaWiki (since 1.19/cb0cf72eba9ff456b4c4e0b5ca54f498265cf82f).

To call api.php it is also possible to use $.ajax or some old things like document.write + script tag.

In T273473#7864181, @XanonymusX wrote:

In T273473#7864121, @AlexisJazz wrote:

Ah, I suppose this is the place to comment. (I had posted this on T302046 but this task seems more appropriate) Feedback time!

That left-of-the-article TOC is a horrible nightmare. I absolutely hate it. I would seriously avoid any website that forced it upon me. Can't scroll it out of sight, can't collapse it, can't disable it, takes up too much space, I hate it I hate it I hate it. This was the reason I switched back to Vector classic on beta cluster. (and if Vector classic gets it too I'll switch to Monobook, Timeless or just murder it with a userscript) I'm not much of a fan of Vector 2022 (but it's not a lost cause, just needs work), but this TOC pushed me over the edge.

As a personal note: I rarely use the existing TOC. But I can scroll it out of sight so it doesn't bother me. If the TOC went completely missing tomorrow, I wouldn't miss it. Having this big, (to me) useless thing that contrasts with the main content (it's much darker) permanently in my field of vision greatly annoys me. And because of the fixed position, my banner blindness fails to kick in. This results in pure hatred for something that, on the face it, could seem innocuous.

I don’t think Phabricator is generally the right place for this type of feedback, there is a dedicated page for it on mediawikiwiki. Here it only makes sense if you can point out more specific bugs/improvements you note. I think that a possibility to collapse/hide the new TOC would indeed be a good idea. The design, on the other hand, is far from final atm, so I wouldn’t bother about that too much.

upload.wikimedia.beta.wmflabs.org still broken.

In T306436#7866172, @matmarex wrote:

Caused by https://commons.wikimedia.beta.wmflabs.org/wiki/MediaWiki:Gadget-betaCommons.css

I get "Exception in store-localstorage-update" and "The quota has been exceeded." on https://test.wikipedia.org/wiki/. At the same time, enwiki doesn't seem to be affected.

Ah, I suppose this is the place to comment. (I had posted this on T302046 but this task seems more appropriate) Feedback time!

Comment moved to https://www.mediawiki.org/wiki/Talk:Reading/Web/Desktop_Improvements#I_hate_the_new_TOC

In T306319#7862293, @Umherirrender wrote:

You can write

api = new mw.Api;
api.postWithEditToken( {format: 'json', action: 'options', change: 'userjs-Test1=testvalue1|userjs-Test2=testvalue2' } ).then( function ( data ) { console.log(data);});

as this (to get mw.Api adding | or \x1F)

api = new mw.Api;
api.postWithEditToken( {format: 'json', action: 'options', change: [ 'userjs-Test1=testvalue1', 'userjs-Test2=testvalue2' ] } ).then( function ( data ) { console.log(data);});

or this (to add it directly in the arguments)

api = new mw.Api;
api.postWithEditToken( {format: 'json', action: 'options', change: '\x1Fuserjs-Test1=testvalue1\x1Fuserjs-Test2=testvalue2' } ).then( function ( data ) { console.log(data);});

but https://en.wikipedia.org/w/api.php?action=help&modules=options says how the api call has to look for the server, when using api.php directly. When using mw.Api some doc is at https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.Api, but that does not inform about multi-value arguments at all.