Any updates on this?

In T242763#5802824, @SBisson wrote:

In T242763#5802793, @Mholloway wrote:

Ah, OK, I see that if you are requesting directly from a mobileapps service instance, then the redirects won't be resolved and the type will indeed be no-extract. I recommend using the public REST API summary endpoint.

Can you elaborate here?

Some thoughts on the current stated task goal:

• webservice is currently python2 compatible
• webservice is installed in all Toolforge Docker containers, many (most?) of which do not include python3
• We have jessie containers still and no active plan to deprecate them (which we probably need to figure out soon?)
• Python lovers are excited for the death of python2, but we will not have a python2-free distro until Bullseye which will be sometime in late 2021 (probably 2022 before it is active use in Toolforge)

The right fix for this is to build a new monitoring system which I'm not going to dive into immediately

@Shahadat Bad news... the copyright detection service we use does not support Bengali :(

https://wikitech.wikimedia.org/wiki/News/2020_Kubernetes_cluster_migration

In T242823#5804161, @Xaosflux wrote:

Couldn't this still be warranted? Example scenario:

1. Delete a page
2. Use Revdel for something like only some edit summaries
3. Restore the page

This results in the page being restored, but the revdel'ed summaries staying revdel'ed

Also, the page could be deleted, and certain revisions are further revdel'd with suppression options.

Basically, this sounds like a useful feature, not a bug.

Couldn't this still be warranted? Example scenario:

1. Delete a page
2. Use Revdel for something like only some edit summaries
3. Restore the page

In T223315#5804097, @Krinkle wrote:

This task is about the processing of submissions, from Special:EditWatchlist/raw and Special:EditWatchlist/clear. The main problem is that, after you're shown the list and indicated what you want to change and submit it, that processing such submission is slow.

Task T41510 is about the the displaying of the checkbox-based interface at Special:EditWatchlist. The main problem there is the expensive nature of generating that many checkboxes whilst displaying the page. It is not about processing its form submission.

I hope I got that right, and if I did, that it made sense :)

Yep, makes sense now

I guess somebody cleaned up the page since this task was filed, as I don't see the comment a 02:50. I see the comment at 16:30 (the first comment on the page) and I can reproduce the problem with it, though. For reference, I was testing on this revision: https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Talk:Cats&oldid=410946

See example at https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:Log&page=T242823

03:44, 15 January 2020 DannyS712 talk contribs block changed visibility of a revision on page T242823: content hidden, edit summary hidden and username hidden (Demo T242823) (diff | more...)
03:44, 15 January 2020 DannyS712 talk contribs block deleted page T242823 (Delete) (view/restore)
03:43, 15 January 2020 DannyS712 talk contribs block created page T242823 (create)

In T223988#5775582, @Hmxhmx wrote:

@Catrope Would that PR also solve the same problem with dates in Special:Notifications?

@Aklapper @epriestley would it be possible for the details to also include a list of the subscribers?

@Mrjohncummings In the sidebar at right,

1. click "Edit related tasks" and then click "Close as duplicate"
2. in the box, paste T242489
3. click "Merge"

:)

Was about to report this.
To reproduce, visit https://en.wikipedia.org/wiki/Special:AbuseFilter/test?wpFilterRules=true and examine an entry

@fgiunchedi all yours

This task is about the processing of submissions, from Special:EditWatchlist/raw and Special:EditWatchlist/clear. The main problem is that, after you're shown the list and indicated what you want to change and submit it, that processing such submission is slow.

Patch-For-Review https://gerrit.wikimedia.org/r/c/VisualEditor/VisualEditor/+/564833

If you try and add a comment while pushing using https://gerrit.wikimedia.org/r/Documentation/user-upload.html#message the hashtag comment will also overwrite that one - see https://gerrit.wikimedia.org/r/c/mediawiki/extensions/TemplateWizard/+/564832

Minimal test case for reproducing this:

<ul>
	<li>A</li>
	<li>B</li>
	<li>C</li>
	<li>D</li>
</ul>
<style>
ul { display: inline; }
</style>

Open this in your browser, the select from B to C and copy-paste into NWE. (If you select the entire list, the bug might not happen.)

Here's where that [[ https://wikitech.wikimedia.org/wiki/Analytics/Data_Lake/Edits/Mediawiki_history | mediawiki_history ]] dataset is helpful:

The above patch is waiting for the help page to be more than a placeholder before it can be merged.

Thanks for catching that @dom_walden.

I've reviewed the commits since 5.1.17 and nothing else stands out to me. Perhaps 998157ac57ffe768a4023 is useful for best practices, but I haven't reviewed the code in question and am not sure if it's something we are affected by currently.

1. Bias / other direction

Any progress on this? Upload by url has literally been around for years and being unable to import from *.wikimedia.org is a pretty massive oversight.

@daniel Remember to enable the thumb channel in production, or, given this is probably temporary instrumentation, perhaps use AdhocDebug instead (and cherry-pick to wmf, leave unmerged in master).

For that you can use Project_talk. Try https://en.wikipedia.org/wiki/Project_talk:Test and https://commons.wikimedia.org/wiki/Commons_talk:Test for example.

@Jpita - Yes, it has been, but Niklas subsequently found another issue (Closing the dialog via Esc or clicking on the overlay was not removing the setlang parameter from the URL) which was fixed in a separate patch - https://gerrit.wikimedia.org/r/564559. Lets wait for that to get merged and deployed too.

In T241584#5784248, @dhunniger wrote:

NFS storage is Ok me.
[...snip...]
And of course it is Ok if you can provide the storage starting from August 2020, since I will need until then to prepare the PDFs anyway. And it also don't matter if you need a few more month.

@Sushant_savla Ji, Every page is redenering with script. Do you wait to load the page? Please wait because userscripts only runs after the DOM is read.

The fields are currently defined in tables.sql as int unsigned which is a 32-bit type with a range from 0 to 2^32 - 1 (one byte shy of 4 GiB). To record sizes of files of 4 GiB or higher, redefining them as bigint unsigned, a 64-bit type, would be required.

I updated all of the target wikis with content.
@Whatamidoing-WMF can you scan to make sure there's nothing obviously wrong with the formatting etc?

this is now being handled as part of T236972

In T163362#5105971, @Dzahn wrote:

duplicate of T163339 ?

Ah, yeah -- I suspect the patch with the forked highlighting/display behavior should carry over to Ferret without significant changes. This is also still behavior I plan to bring upstream in some form, I just wasn't satisfied with my initial stab at it back in the day.

We should try to fix this before deploying V1.1.0. Ready for Development.