I'll be wrapping the mobile presentation in another layer of markup as part of this task, so this will be resolved in this task.

We verified in testwiki that the correct message id is being used, however the translations will need to be updated to use the abbreviated version to completely resolve the issue.

verified on testwiki

verified fixed on testwiki

verified fixed on test wiki

okay the ores namespace config patch has been backported

+2ed the ORES patch and scheduled the config patch for backport later today

Okay, I closed it out; if somebody else runs across a case that we missed, please do reopen!

I did 3 runs of my script (~ 9 minutes of scrolling the feed) now that enwiki is on 1.46.0-wmf.12 and found 0 duplicates! You can see the filter settings in the first screenshot below. I'll leave this open for now to see how it's looking for the NPP folks.

What do we gain from making this change? If we don't have a compelling answer, I think renaming this would be work without benefit.

Now that I'm that I'm looking for this in the requests, I can see that my script is missing some duplicates; I'll see if I can correct that

okay, looking closely at the requests, here's what I see at the rollover:
last 2 good list requests before rollover:

I verified that testwiki does show the right commit for PageTriage without the debug host:
https://test.wikipedia.org/wiki/Special:Version#mw-version-ext-specialpage-PageTriage

hmm; I rechecked on the debug host on a whim. I'm still seeing 0 duplicates on the debug testwiki host.

To reproduce, log into test wiki and load my script from your common.js; mine looks like this:

// see https://phabricator.wikimedia.org/T414892
mw.loader.getScript( 'https://en.wikipedia.org/wiki/User:JSherman_(WMF)/T414892.js?action=raw&ctype=text/javascript&date=2026-01-21.1' );

note that I added a date param to bust cache as I update the test script.

Bad news; I realized that my testing on test was not going far enough back; I amended my script to allow multiple runs that add on to the already loaded list (instead of repeatedly starting from scratch) and I'm now able to consistently get duplicates on testwiki, which has the patch

Backported to test wiki and looking good there:

I made a little user script to check for duplicate pages:
https://en.wikipedia.org/wiki/User:JSherman_(WMF)/T414892.js
It adds a toolbox link that scrolls the page until there are no more entries, checks for duplicate titles, and lists them in an alert. Nothing fancy, but this should make testing much quicker during deploy since I won't have to catch new duplicates by eye.

I wasn't able to reproduce this issue beta wiki, but I did verify that the patch doesn't break things; it seems to do the job locally, so I'm going to backport this during tomorrow's UTC afternoon backport window:
https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20260121T1400

I think CC support will be the biggest question here; I'll followup with more info to make this estimatable.

That said, unregistered editors now have fewer total edits on average (since they're shorter-lived), but we'd anticipate that this would increase RR scores on average, since lower number of total edits correlates with higher score. T376116: Implement support for temporary accounts in revertrisk models is about analysing behaviours.

verified working on enwiki beta

https://github.com/WikipediaLibrary/TWLight/pull/1498 is ready for review

The work for this task is in master:

I'm pushing all of the changes to ezproxy production; we'll need to update BioOne in TWL once the change lands.

I'm pushing all of the changes to ezproxy production; we'll need to update BNA in TWL once the change lands. FMP can stay disabled for now.

@Samwalton9-WMF I'm wondering if it has to do with authorization within FMP. I see the message says we have access to "certain records" and I am clearly getting some errors coming from within their platform.

@Samwalton9-WMF I've pushed these changes to the ezproxy preprod environment and reset the twl staging environment to match the current production state. You may now update the partners in staging and test.

@Samwalton9-WMF I've pushed these changes to the ezproxy preprod environment and reset the twl staging environment to match the current production state. You may now update the partners in staging and test.

update: it's pretty clear that this bulk mailing is off-label for the cloud vps infrastructure. For this survey, we're going to try using the mediawiki email user api instead. It's something we have previously explored, so we have some PoC code on hand already.

This happened again in the UTC late backport window:
https://sal.toolforge.org/log/5jwwKZsBvg159pQrFeSI

In T412427#11466096, @taavi wrote:

In T412427#11465127, @Samwalton9-WMF wrote:

I agree in general, but for expediency we're happy collecting emails for now (we received 6 requests from what looks like ~5000 emails sent) and then we could upload these in the future if we add such a field/option.

Unfortunately that's not including the couple dozen bounces that we got in via root@ that made me notice this in the first place.

So, the envelope sender/From header is still a bit of an open problem:

• The envelope sender and From: must be on the same domain for deliverability reputation reasons.
• That domain in use must also pass SPF+DKIM, which restricts us to wmcloud.org (or wmflabs for legacy stuff, but that's not applicable here).
• Bounce messages are sent to the envelope sender, not to reply-to (which is used by humans and autoresponders), which means:
• The envelope sender address must not bounce on its own, which in practice means using root@ or some of the other aliases on that domain routed to some WMCS SREs.

We've been tolerating the occasional bounces sent to root@, but for a mass mailing of this size it would be much better to send those to you to be able to remove the addresses from your listings. It is unlikely that we'll find time to engineer a proper, general solution for that anytime soon, but I'll check if we can figure out some manual hack for this.

In T412427#11466099, @taavi wrote:

Also, how have you validated the addresses users have given to you? From the brief batch of mails that was sent out last week, I can see several total nonsense addresses that could have never worked (think of [something]@en.wikipedia.org or similar) so I'm not sure how those got to your list?

okay, I'm forking our email middleware and implementing changes there.
https://github.com/WikipediaLibrary/djmail/tree/Jsn.sherman/T412427

Oh yeah, I meant to comment on:

Another thought: we could be batching these using BCC.

Thanks for this @Samwalton9-WMF!

Okay, I've done some of the underlying structural cleanup.