Yes, combining Kartographer with FlaggedRevsOverride causes some problems. We'll still enable Kartographer on your wiki if you want it, but you should know about this bug so that you can make an informed decision.

Setting this one aside for Jazmin to work on over the Wikimania hackathon

I null edited https://nl.wikipedia.org/wiki/1870-1879 , and the photo of Aletta Jacobs changed from 220px to 260px. Unfortunately a null edit is required to trigger the update, a purge is not sufficient. That's OK though, removing the largethumb template from an article would also involve editing it.

@Krinkle, @Ciell and I discussed this at Wikimania, and we decided that it would be best not to remove 200 and instead just change 250 to 260. That way the default size index changes (from 4 to 5), but that's less disruptive than what would happen if we removed 200 in the middle: someone whose preference was e.g. 300 would see it change to 400, and I don't even know what would happen to users whose default was 400 (their size index would become invalid).

Should this change be made only on mobile, or only on desktop?

This task is only for mobile, but the CSS rule would apply to both mobile and desktop. Should this change be made for both mobile and desktop? It seems to me that the ratio between the font size of the number and the font size of the text to the left of it should be consistent between desktop and mobile (right now it's 1:1 on both).

There's a letter-spacing: 0.02em rule on these because you asked for it here: T218966#5130398

You asked for both the font-size: 0.85em and letter-spacing: 0.02em rules here: T218966#5130398.

There's a letter-spacing: 0.02em rule on these because you asked for it here: T218966#5130398

Specifically, I think it would be good to sketch out how we would implement some of these things (at least "maintenance template" and "newest articles", as you say), and especially what kinds of new storage we would need (database tables, caches, etc.).

We should check if this still happens in production. The latest patch would have changed how the error is reported in Logstash, we should now search for "Job push failed".

It sounds to me like we just need to do the usual threshold configuration, like in the commit Aaron linked. So we just need to do each of the subtasks.

In T229235#5387097, @MMiller_WMF wrote:

@kostajh -- how common is this? What percent of users are not getting a mentorship module?

I believe this FOUC is part of MobileFrontend's relative timestamp handling, because the "Last edited 24 days ago" label at the bottom of the user page behaves the same way.

This bug is very obviously visible if you open e.g. the "ask your mentor" dialog on the mobile site in a desktop browser at full size (without device emulation). The OOUI dialog doesn't cover the whole screen (because the screen isn't small enough to trigger that behavior), and you get this:

The attached patch fixes this by changing the way the impact module uses column layouts. Right now, the "Monitor views" and "You have not yet created" labels take up the entire width of the module, and then the "Views from recent edits" and the pageviews number are in a 2-column layout (where the left column is as wide as possible, and the right column as wide as necessary). With my patch, the entire module is a two-column layout, with all the text in the left column, and the number in the right column (bottom-aligned). This means that we don't get weird display issues when the number is taller than the "Views from recent edits" text, and hacks fighting those display issues is what made it hard to bottom-align the number in the first place.

This is also reproducible in English, you just have to make the screen narrower so that the "Views from recent edits" text wraps:

It appears that a simple way to fix this would be to add 2600 (the ID of the Topic namespace) to the 1, 3, 5 list in the code snippet quoted in the task description.

I can't reproduce this on beta labs. It was probably fixed by something we did in the past 6 weeks.

In T132084#5348539, @AVasanth_WMF wrote:

While we could potentially get away with one notification being sent to relatively new editors, retroactively notifying editors might cause some stir we aren't prepared to handle at the moment.

The first stack trace is from a deferred update scheduled from EchoHooks::processMarkAsRead() on read requests with a ?markasread=123 query parameter. If writing from deferred updates on GET requests is not allowed, how are we supposed to schedule a write when we notice that it's needed in a GET request? Do we submit a job to the job queue?

(2) A protected page has 'View source' option for users who cannot edit protected pages. Clicks on 'View source' won't trigger impression event.

Patch was merged, job is no longer failing

Perhaps this could be a good onboarding task for @Tgr ?

If Parsoid doesn't make breaking changes that cause old HTML to fail to serialize back to wikitext (and Subbu told me that was not intended), then this should not cause any problems. We'd have to update the endpoint config but that's it, and we can test that in beta when the time comes.

I see the following rules for Arabic in plurals.xml:

<pluralRules locales="ar">
    <pluralRule count="zero">n = 0 @integer 0 @decimal 0.0, 0.00, 0.000, 0.0000</pluralRule>
    <pluralRule count="one">n = 1 @integer 1 @decimal 1.0, 1.00, 1.000, 1.0000</pluralRule>
    <pluralRule count="two">n = 2 @integer 2 @decimal 2.0, 2.00, 2.000, 2.0000</pluralRule>
    <pluralRule count="few">n % 100 = 3..10 @integer 3~10, 103~110, 1003, … @decimal 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0, 10.0, 103.0, 1003.0, …</pluralRule>
    <pluralRule count="many">n % 100 = 11..99 @integer 11~26, 111, 1011, … @decimal 11.0, 12.0, 13.0, 14.0, 15.0, 16.0, 17.0, 18.0, 111.0, 1011.0, …</pluralRule>
    <pluralRule count="other"> @integer 100~102, 200~202, 300~302, 400~402, 500~502, 600, 1000, 10000, 100000, 1000000, … @decimal 0.1~0.9, 1.1~1.7, 10.1, 100.0, 1000.0, 10000.0, 100000.0, 1000000.0, …</pluralRule>
</pluralRules>

In T228991#5371448, @kostajh wrote:

Oh, because in LTR languages we're looking for ]]| but in RTL languages we need to find |[[

I'm now seeing this as 29% of the wall clock time for a startup module request on enwiki: https://performance.wikimedia.org/xhgui/run/callgraph?id=5d3b723cbb8544407f9cb8ae

This sounds good to me.

It doesn't seem to me like there's anything to SWAT:

$ git log origin/wmf/1.34.0-wmf.15..origin/master --oneline
7017917 (origin/master, origin/HEAD) Localisation updates from https://translatewiki.net.
943ce85 (cog-popup-alignment) Help panel: Fix cog popup alignment

In T222852#5366546, @kostajh wrote:

I’m not sure we SWATed the patch to prevent this.

I've figured it out: rMW383460afa3b7: objectcache: normalize BagOStuff method overriding pattern for *Multi() methods changed the behavior of convertToRelative(), such that convertToRelative( 0 ) used to return 0 but now returns 1. This is incorrect (or at least unhelpful), because RedisBagOStuff does $ttl = $this->convertToRelative( $exptime );, then checks whether or not $ttl is zero to determine whether to set a TTL or not. But as currently written, convertToRelative() can never return 0, so in code like if ( $ttl ) { ... } else { ... } the else branch is never taken.

The TTL gets set to 1 somehow...

This appears to be happening because MainStash / Redis has broken handling of $ttl = 0. It's supposed to mean "forever", but it looks like it's being taken to mean "expire immediately":

Something's definitely wrong here...

This turned out to be a regression dating back to late April: rEFLW939d956727ed: Autosave comments

The thresholds are cached in memcached, and our memcached servers had some issues today. The spikes you saw were almost certainly due to MW experiencing errors contacting the memcached servers, and falling back to contacting ORES directly (because a failure to reach the memcached server looks the same as a cache miss).

This is a GSoC task. Moving to External since that's what we appear to have done with other GSoC tasks.

I think we can drop these indexes. I'm not aware of any code that needs them. If MySQL's metrics show that these indexes really are unused in production, then let's drop them.

Sorry for the late response on this task.

Scheduled for Wednesday July 24th at 23:00-00:00 UTC (4pm PDT).

Here's how I determined that mobile.startup (which uses ResourceLoaderFileModuleWithMFConfig) is the only content-versioned module that uses LESS:

To illustrate this problem, see this xhgui analysis of a cold-cache request for the startup module on mediawikiwiki in de-ch. Highlights:

• It took 18.2 seconds the first time (cold cache) and 11.8 seconds the second time (hot cache); for lang=en this was 1.4s / 1.1s
• 85% of this time (15.4 seconds) is spent in Message::fetchMessage and the things called from it;
• There are 6381 calls to MemcachedPeclBagOStuff::doMulti collectively taking 4.1 seconds, and 3190 calls to DatabaseMysqli::doQuery collectively taking 2.1 seconds

In T220146#5329872, @MMiller_WMF wrote:

I made a calendar invite for Roan and me to delete them next Friday.

I accidentally dropped the reference to this task from the patch, but it's now merged.

In T227575#5340660, @Cntlsn wrote:

@kostajh thanks, it works good! I only have a little UI note, can we wrap

<div id="mw-content-text">...</div>

into

<div id="bodyContent" class="content">...</div>

just like in User:[username]? This way it should gain a bit of margin on the sides.

Once this is ready to go into production two weeks from now (and once https://gerrit.wikimedia.org/r/c/mediawiki/extensions/TheWikipediaLibrary/+/524062 has been merged), I'll enable this in test.wikipedia.org first, and @Samwalton9 and I can then discuss where to roll it out from there.

In T132084#5346565, @Samwalton9 wrote:

Does this mean the notifications are now live?!
And just a quick check - is this only going out to newly-eligible users or will people who've already crossed the threshold get a retroactive alert? Just curious.

This is probably a duplicate of T211798, right?