In T422559#11796709, @taavi wrote:

Seems like mx-in*.wikimedia.org do not like these emails for whatever reason

see also T393124: Use full month name in date

retargeted the link to bypass redirect so this is less visible to readers now. https://en.wikipedia.org/wiki/special:diff/1343912188

this is still cached/reproducible 20+ hours after page move. I even did locally in OS settings clear data, didn't help.

cc @Dbrant

https://wikitech.wikimedia.org/wiki/Incidents/2025-02-28_www.wikipedia.org_redirect

see also previous XSS was fixed: https://github.com/StarCitizenTools/mediawiki-extensions-ShortDescription/commit/bc4fdbaeb1dff127fb6d08c0d385b64aa128c8f8

unclear to me why this was filed publicly? the github link is embargoed I guess, 404 for me.

In T413376#11639023, @Gopavasanth wrote:

Could you please share any reference or guidance on how to properly fetch the latest deployment details?

In T413376#11639020, @Gopavasanth wrote:

@bd808 fixed it! https://github.com/indictechcom/TranslateTagger/pull/23/changes Good to go?

fetching github from client JS isn't permitted and anyway it doesn't make sense.

In T415237#11612824, @Wargo wrote:

Most important may be the button to export pad to MediaWiki, even with some history attributions.

In T415237#11606312, @doctaxon wrote:

We have Commons. Isn't it a gigantic database too?

maybe of interest I stumbled on this also tonight.

In T415237#11604318, @Volans wrote:

I've looked at it and having a solution that will slowly go over the existing pads older than X and delete [optionally archiving too] them is very easy and will take a day or two to implement.

your NY times links are all Unable to load URL. for cbc I get a response sourced from wayback instead of zotero and VE is broken with We couldn't make a citation for you. Try another source or create one manually.

It's like the results if I ran the queries 3 or 4 days ago. Is the database not been updated since 1/14/26?

In T81605#11530397, @cmooney wrote:

As a further test I wiped my cache, started a packet capture and did a dig for 'en.wikimedia.org'.

originally added in T354679: Add dumps mirror for data1.usrdm1.scatter.red

In T198138#11436334, @Physikerwelt wrote:

I still don't understand what would be the best way to clone a git repo from within an potentially unsecure labs instance.

new key, same problem. f95b48c236e08bf8f7a9e482e4382aec0b9f1bd7

In P71784#287826, @jeremyb wrote:

looks like there 6 removals not replaced with something approximately the same.

if they only include those with at least 1% of responses for a block and they're always adding new data then maybe something dropped below 1%.

In P71784#287826, @jeremyb wrote:

looks like there 6 removals not replaced with something approximately the same.

if they only include those with at least 1% of responses for a block and they're always adding new data then maybe something dropped below 1%.

looks like there 6 removals not replaced with something approximately the same.

https://www.nytimes.com/interactive/2023/upshot/extremely-detailed-nyc-neighborhood-map.html

@awight @Jdforrester-WMF is this still stalled? where is the best place to track how much is done and what's still needed?

looks good to me. I saw no banner there and then added Wikitech to an active campaign and then removed Wikitech from campaign and was still seeing it and then didn't see it and then deleted impressiondiet from session data locally in my browser and then saw it again (not in allocation but still within the 10 minute caching period) then waited for 10 minutes to expire and deleted impressiondata again and then it really doesn't appear. then did another test to see what shows in allocation, turned same campaign on for Wikitech and showed up immediately in allocation and then removed Wikitech from campaign and disappeared immediately from allocation.

Looks like this is set at https://gerrit.wikimedia.org/g/mediawiki/extensions/UploadWizard/+/d0572ccc8f27d024d012f5a94051ef6eebe9c1d6/UploadWizard.config.php#568

found T376509 while investigating 429 for https://upload.wikimedia.org/wikipedia/commons/thumb/7/74/Feedback_form_Odia_Wikipedia_outreach.pdf/page1-180px-Feedback_form_Odia_Wikipedia_outreach.pdf.jpg

sure, of course, I just thought we were trying to unify without that? (or else docs were confusing)

@Kitabc12345 also I'm wondering if there's been any local discussion about https://en.wikipedia.org/wiki/Banner_blindness ? (no article on this topic in zh yet)

In T375253#10163560, @Kitabc12345 wrote:

privacy concerns with relevant APIs

is this UBN? high for now.

copying over comment from other task:

put this on hold for now. Will come back if I have a more solid plan for how I would use it regularly.

this is moot now, event is in less than 2 days, closing. I'll write something up soon in case someone wants to reuse my methods.

I found this form. didn't try it yet. https://toolsadmin.wikimedia.org/profile/settings/change_password/

@Ejegg is there any possibility of a compromise where the default preview does this but if a user needs to share with community members they can add a query string param that makes clear that they really for sure understand what they're not allowed to include for privacy policy? &confirmedPrivacyPolicyFollowed=1 not a huge deal for me right now since I learned why it's there but maybe other CN admins (or me in the future) need to share more with ordinary users.

I believe https://meta.wikimedia.org/wiki/Special:CentralNoticeBanners/Edit/Wikicurious_beat_talkpg_en is ready to ship. wgCategories only, talk page only, no array or regex, wrapped in a https://en.wikipedia.org/wiki/Immediately_invoked_function_expression

There's some low hanging fruit I found to move some to regex. see counts at P68997. that's just from removing /\b\d+(nd|rd|th)?\b/ from titles. aka numbers.

In T374394#10138675, @Jdlrobson wrote:

How about a build step where you generate an array of title pages that match the categories once and then providing this as a static array. Presumably category members won't be changing enough to warrant an API request on every page?

https://meta.wikimedia.org/wiki/Talk:CentralNotice#CentralNotice_documentation

If the goal is displaying banners based on categories, that seems like something that perhaps MediaWiki-extensions-CentralNotice itself should provide when setting up a banner campaign e.g. only show banner on pages with these "Categories" and check a box "include talk page categories". That seems like a useful feature?

In T374394#10135913, @Ladsgroup wrote:

Stewards only show CN notice in logged in users and desktop only, it's a very small portion (and probably didn't need that query anyway, mw.config.get('wgUserEditCount') which is not exactly what it wanted but close enough.

In T374406#10133385, @Ladsgroup wrote:

It first needs a sponsor from a wmf staff.

In T374394#10133179, @Ladsgroup wrote:

That can easily bring down everything specially since API requests don't get CDN cached.> > If something is not possible natively in CN, it's better not to circumvent it by API calls.

In T374394#10132082, @Ciell wrote:

@jeremyb fyi, I disabled both the Spanish and English banner per this report.

In T353611#9413260, @Dbrant wrote:

@Clovermoss Actually, could you just clarify how exactly you arrived at the diff in question? i.e. in which screen in the app were you before tapping on the diff and seeing that it's incorrect?