@ssastry - Do you know of any changes in the HTML rendering on Commons around November 25th that might be related to this?

@atgo - Yes, we'll need to register the campaign for each language wiki as they become supported by the project. We can also register it for all wikis by adding it to the default config, but I wouldn't advise doing that until we have a significant number of languages coming online.

@matmarex - Sent you some info on the project. Also, I forgot to mention that we only need to register the campaign for Indonesian Wikipedia (idwiki).

@matmarex - Can you go ahead and register the campaign (external-machine-translation) per Pau's note above, and then schedule it for SWAT deployment in January?

@jijiki - The first test seems to be hugely improved:
On beta cluster:

@Anomie @EvanProdromou - It sounds like the use case here (from a high level) is that we would like to be able to retrieve from the API the substance of an arbitrary edit regardless of whether it is the first edit to an article or not. Can the API support this use case (either now or in the future)?

@jijiki - Is there a way I can test it, other than locally?

Thanks for catching that @JJMC89! I'll deploy a config change for Test Wikipedia tomorrow so it matches English Wikipedia.

@Pginer-WMF - This is ready to go now. All we have to do at this point is register the campaign via a config change so that e.g. https://en.wikipedia.org/wiki/Lion_taming?veaction=edit&campaign=toledo sets the corresponding revision tag. Should we go ahead and do that?

@Etonkovidova - note that you can see which articles transclude a {{NOINDEX}} template at https://en.wikipedia.org/wiki/Category:Noindexed_articles.

@Etonkovidova - Here's how it should all pan out after the patch is deployed:

• Unreviewed article, less than 90 days old, no {{NOINDEX}} transclusion: outputs <meta name="robots" content="noindex,nofollow"/>
• Reviewed article, less than 90 days old, no {{NOINDEX}} transclusion: doesn't noindex
• Unreviewed article, more than 90 days old, no {{NOINDEX}} transclusion: doesn't noindex
• Reviewed article, more than 90 days old, no {{NOINDEX}} transclusion: doesn't noindex
• Unreviewed article, less than 90 days old, {{NOINDEX}} transclusion: outputs <meta name="robots" content="noindex,nofollow"/>
• Reviewed article, less than 90 days old, {{NOINDEX}} transclusion: outputs <meta name="robots" content="noindex,nofollow"/>
• Unreviewed article, more than 90 days old, {{NOINDEX}} transclusion: doesn't noindex
• Reviewed article, more than 90 days old, {{NOINDEX}} transclusion: doesn't noindex

Approved!

@kostajh - Looks like the bug was introduced here: https://phabricator.wikimedia.org/diffusion/EPTR/browse/master/includes/Hooks.php$385. The reason this produces the bug is that wfTimestamp( TS_MW, false ) returns the current timestamp, not false or null as you would probably expect. Thus each time PageTriage tried to look up the age of an old article that wasn't in PageTriage's DB tables, it would think the article was brand new.

It seems to at least be sort-of working correctly. For example, these two articles were both nominated for speedy deletion (and thus include the {{NOINDEX}} template):

• https://en.wikipedia.org/wiki/Vps_healthcare_group, created earlier today, does output <meta name="robots" content="noindex,nofollow"/>
• https://en.wikipedia.org/wiki/Golf_(Atari_2600), created 2015, does not output <meta name="robots" content="noindex,nofollow"/>

@Tgr - Good point, I'll tweak the working...

@Banyek - Thanks for the ping. I don't think anything is unexpected here. This particular clean-up routine is expensive, which is why it was put in a cron job. Is there anything I can add to the script to indicate that? If we need to get it running faster than 3 seconds, let me know.

@Steinsplitter - Ah, I see. While extended-reviewers can technically review image licenses now, I think they can be trusted not to violate the review policy (or hack UploadWizard to do a false review). We don't have to enforce every policy with an AbuseFilter, especially for trusted users, in my opinion. I'm open to hearing other opinions though. Of course, the best solution is switching to server-side license review, but no telling when that will happen.

I'm happy to provide the manager approval, but you'll still need a C-level sign-off.

I fixed the AbuseFilter, so this should no longer be an issue. Extended-uploaders are trusted regarding licensing, so I just exempted them from the filter. Agree that moving the check to the server-side is the best long-term solution, but that's covered in T89131.

@Steinsplitter - I fixed the AbuseFilter filter. You forgot to exempt the extended-uploader user group when you added the {{FlickrVerifiedByUploadWizard.*}} template. To be added to the extended-uploader user group, you have to be vetted for knowledge of the licensing policies, and be trusted to import files from Flickr that aren't Flickrwashed, so those users are trusted should be exempted from the AbuseFilter.

@Esanders - It looks like the display:inline-block change caused a different bug, specifically, you can no longer have heiro elements inline in text (T210695). Could you take a look (or revert)?

FYI, the 90 days comes from $wgPageTriageMaxAge.

Could someone write a description for this task? What is the goal here?

@Volker_E - Here's what it looks like without the Horizontal Layout and having both buttons...

Community discussion of the bug here.

Yes please! I've likely received over 100 of these notifications, and every time I do I feel like I've wasted 2 seconds of my life. Granted, that only amount to 200 wasted seconds, but still!

@Gryllida - As Aklapper alluded to, you can thank an admin for deleting a page from the deletion log: https://en.wikipedia.org/wiki/Special:Log?type=delete&user=&page=&wpdate=&tagfilter=

@jmatazzoni - Both of those designs look fine to me. Any preference?

@Volker_E - Any preference on how to fix this?

@matmarex - For now, it's fine if this only works in VisualEditor. Thanks for your quick work on this!

Fix seems to work. Been testing for the last few days and haven't had any cases of not getting the toolbar.

FYI, this has been made into a proposal at the 2019 Community Wishlist.

@Prtksxna - As far as design, I guess we need to figure out if this is a button or a link or what. It doesn't need to be very prominent as I expect it will rarely be used.

@Prtksxna, @Niharika - I'm fine with not having a special page so long as we have some kind of text accompanying the link or button that links off to a help page explaining the data and how to request additional data. So something like "For additional information, see [Help:Downloading account data]." The default message should link off to a help page on MediaWiki.org, although we'll probably want to override this (via WIkimediaMessages extension) to point to a more WMF-customized version on meta.

Yes, the Architecture Committee decided against making users' IP addresses available. You can read through T387 for the gory details. It could perhaps be revisited, but that was the last decision on the matter.

@jmatazzoni - That proposal was rejected by the Architecture Committee (see T387). Otherwise, we could have just deployed the AccountInfo extension.

I tweaked the description to focus on the account data download, since that's all we're doing right now.

Setting to low priority after discussing with legal. The main priority is to provide "personal data", i.e. data about their account rather than content created by their account.

Yeah, just that one for now, AFAIK.

According to the documentation, "This is a status for parameters which should not be used any more." So the best thing to do would be to have VE filter them out, IMO.

@matmarex - For this project, support would only need to be added to VisualEditor. Just to clarify, is it currently possible to create a specific tag that anyone (even anonymous editors) can add (via the API)? I assume so, but would like to double-check.

Still haven't figured out when the original interface was switched to oojs-ui though, which was the more significant UI change.

Haven't narrowed it down completely, but I suspect it may have been https://github.com/wikimedia/oojs-ui/commit/11d868b39f83a79fe6aeefec8c774ae534ff9c95.

It looks like the grid layout aspect was lost due to upgrading from oojs-ui v0.23.0 to v0.23.1.

@Etonkovidova, @SBisson - Looks like its still broken for some reason.

@jmatazzoni, @Mooeypoo - If this task ends up being complicated, for example, if it requires setting up a storage solution, let me know and we will reconsider whether or not it is necessary. From my conversations with Moriel, it sounds like the user data export should be straightforward, but this one may be complicated due to edge cases.

@aezell, @jmatazzoni - We need it to be machine-readable, not human-readable.

We probably won't be able to use CSV for the User Data, since it's not just a key-value list, but a collection of complicated data. For example, the user group list, wiki list, and preferences will be arrays rather than single values. In order to make that data properly machine-readable it will need to be in a JSON or XML file (to handle the different types of data). The User Contributions, however, could probably work as a CSV or JSON.

We should switch the AbuseFilter to be tag-only and make sure the new patch is working correctly. I tried to create a new tag for it, disallowed page creation, but for some reason it won't let me add it. Maybe @MusikAnimal could help.

Note that partial blocks are only currently enabled on Test Wikipedia.

Awesome job, @RHo! I think you did a great analysis on these. One point I would like to add about ArticleFeedbackTool:

Looks good to me.

@Johan - Perfect! Thank you.

Sounds good to me as long as it doesn't screw up the floating toolbars.

Ah thanks! I hope y'all aren't planning on changing it again soon :)

@Carlb - In most cases those links were migrated to the RelatedWikipedia template (or RelatedCommonsCat template). However, in the case of that page in particular, there is already a link to Wikipedia:Civility in the See also section, so using the RelatedWikipedia template would have been somewhat redundant. Alternately, you could create an interwiki link to Wikipedia:Civility in Wikidata if the two pages are roughly equivalent (which would add it to the sidebar). We've tried to migrate as many pages as possible without loosing links (especially in the main namespace), but the process isn't perfect. The links in the User, Wikivoyage, and Template namespaces were mostly just removed since these were considered less critical. Let us know if there are other pages we should re-visit, and sorry if the process hasn't been ideal.