The only way I know of that you can detect reverts is to look for the string "Reverted to version" in the image comment. See, for example, https://commons.wikimedia.org/wiki/File:Glandulicereus_thurberi_sonora.jpg.

@dr0ptp4kt - Sorry for the late feedback. The only topic predictions that don't make sense to me are the "Regional society" and "Regional geography" ones. No one is ever going to choose an interest in "Regional society" or "Regional geography". These either need to be refined to topics like "European society" and "African geography", for example, or just generalized to "Society" and "Geography", although FWIW, "Society" doesn't seem like an especially useful topic either.

@aezell, @Mooeypoo - Makes sense. The original implementation plan was to create a new table called watchlist_props, but without more clear use cases, that feels like it might be over-abstraction. This plan sounds like a good compromise between the two existing ideas.

@daniel - Any personal opinion on which schema we should pursue?

I support matching the pattern that was used for usergroup expiry, which I think was mostly implemented by @TTO. For the schema changes, this would mean adding a varbinary column to the watchlist table to store an expiration timestamp and also a corresponding new index for that column. Maybe @TTO could elaborate on the rest of it (queries, garbage collection, etc.).

I'm going to be bold and mark this as declined. This is no longer stalled by wl_id, but it seems the current plan (T124752) is to implement something simpler: just adding an expiration column to the existing watchlist table. This seems sensible, especially since it will match how user rights expiration was implemented and thus follow an existing pattern. If anyone disagrees, feel free to reopen this task.

FYI, there's already a bot on Commons that is doing this for existing images, so having it happen automatically in UploadWizard shouldn't be controversial.

@MusikAnimal - This particular problem is definitely due to API access restriction, not quota issues. Do you know if anything changed about how the proxy communicates with the outside world? I tried adding 185.15.56.49 to the whitelist (the current public IP address of the proxy), but that didn't seem to work.

I'm going to temporarily remove the IP address restriction. The IPs listed in the whitelist were:
208.80.155.245
208.80.155.189
88.147.99.47
58.96.117.10
185.15.56.0/24

The error is definitely coming from the IP address restriction, however, I tried adding both 185.15.56.49 and the entire 185.15.56.0/24 subnet to the whitelist in the Google developer console, but neither fixed the problem. @bd808 @Bstorm - Any idea what might be happening here? Did anything change related to Tool Forge's external IP addresses around January 23rd? For reference, here's the Google API proxy documentation.

If it makes any difference, I endorse this change (as one of the original authors of UploadWizard). Note that no one really owns UploadWizard currently (as we don't actually have a multimedia team at the moment), so it's basically just in maintenance mode, i.e. bug fixes. If you want to get a feature change like this done, you'll either need to convince one of the people who is familiar with the extension to work on this in their spare time or have a volunteer developer work on it. I imagine the WMF will re-convene a multimedia team at some point, so worst case scenario would be to wait until then.

I finished up the page and published it.

It looks like @jeropbrenda did some work on this in November: https://www.mediawiki.org/wiki/API:Get_the_contents_of_a_page.

No longer stalled since wl_id has been implemented on WMF sites.

No longer stalled since wl_id has been implemented on WMF sites.

No longer stalled since wl_id has been implemented on WMF sites.

@ppelberg - It's working for me now.

As the original author of the bug (from 4 years ago), I would say yes.

It definitely should be (and was until recently). Not sure who is responsible for keeping those services up...

I think @mobrovac was in charge, but he left the WMF last week. Maybe @cicalese knows.

It doesn't seem like there is consensus for this change. FWIW, it seems like a bad idea to me, as it would make the article backlog even worse (which is currently at 6660 pages and rising). Unless someone can point to a consensus discussion to implement this, it should probably be closed as DECLINED.

@ppelberg - JK says it isn't urgent. Let's circle back on this after the holidays.

When I try to load the page, the ext.discussionTools.parser module makes a call to RESTBase for https://en.wikipedia.beta.wmflabs.org/api/rest_v1/page/html/Talk%3ACats/407862?redirect=false&stash=true which returns a 503 server error.

Is there are specific thread where this happens?

@Esanders - I tried multiple threads. The error is consistent for me. I can reload the page and still get the same error. Also tried in Firefox and got a similar error: "RESTBase load failed: Service Unavailable".

Are you logged in?

No. The instructions don't say anything about logging in, so I didn't.

Can you reproduce with the developer console open and see if there are any errors or warnings in the console?

None other than the ones reported in the description. Note that the errors occur at load time, not at posting time.

@Krinkle, @Mooeypoo - I'm wondering if we could kill 2 birds with one stone here. On the one hand, we need some testing grounds for FAWG to try out the new JS framework that will be integrated into MediaWiki (which I imagine will include templating capabilities). On the other hand, we need to reduce our dependency on lightncandy/mustache in cases where we don't have resources to update and maintain those extensions for new versions of lightncandy. Perhaps we could beta test our new JS framework by migrating some of the old uses of mustache templates to the new framework. See T121947#5749594 for a list of potential targets.

@kzimmerman - Thanks for looking into it.

We may also want to repeat File:Analysis of Wikipedia Portal Traffic and JavaScript Support.pdf but other page(s)?

@mpopov - Yes, that would be super helpful for the other part of parent task T234695!

"Edits done" means edits completed.

Thanks for working on this! Note that it not only affects gadgets and user scripts, but also WMF software like PageTriage and Who Wrote That:

"Curate this page" was changed to "Open Page Curation". As far as I know, that link was never displayed on pages unless they were currently in the queue or had recently been in the queue.

Do you really mean "to OOUI", the library, or just as a MediaWiki widget? Are there use cases where adding this heavy functionality is necessary for non-MediaWiki environment tools e.g. things on ToolForge, or is this for use in extensions and gadgets?

Either one is probably fine.

I also belatedly endorse this, as Max's manager's manager :)

@hoo, @Bene, @Eisheeta - Someone still needs to add some real documentation for this extension, i.e. what the heck does it actually do and how do you use it? I'm surprised the extension got deployed without it.

@jayantanth, @Bodhisattwa, @Samwilson - An update: Kannada, Telugu, and Panjabi are now properly supported by the Google Vision API. Malayalam, Oriya, and Gujrati are still broken, however.

@Niharika - This is something that AHT team wants, correct? Huji's already done some work to add the geoip2 library and some related MaxMind components as a dependency to core (which actually dates back to our work on LoginNotify), so we could go ahead and request an initial security review, if this seems like it would be useful to you (for CentralAuth and/or LoginNotify).

@Niharika - This is just a code maintenance issue. No user-facing features would actually be affected by this (although it might make it easier to build such features).

@Huji - Has geoip2 been security reviewed by the WMF yet? I saw that @Reedy had looked over the patch, but not sure if anyone's done a formal security review. If not, let me know if I can help with that.

I'll bring this up with the WMF partner folks.

It looks like this task is done. Please close it and open a new task for any remaining issues, otherwise, it is hard to track the progress of the project. Thanks!

Looks like @Esanders inadvertently broke it while making the code more linter compliant:
https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/UploadWizard/+/541298/1/resources/mw.UploadWizardUploadInterface.js

It looks like the placement of the mwe-upwiz-file-texts div in the DOM has changed.

@matthiasmullie @Volker_E - No idea what caused this, but any chance one of you could look into this?

This seems to be caused by the following CSS rule (which I'm assuming is generated by JS):

.mw-kartographer-map .mw-kartographer-fullScreen .oo-ui-iconElement > .oo-ui-buttonElement-button > .oo-ui-iconElement-icon {
    left: 0.35714286em;
}

Which overrides another CSS rule that sets left: 50%;. Disabling the rule above (so that the left: 50%; rule has effect) fixes the button.

I added a new example query at the API:Revisons documentation which shows how to follow redirects. Surprisingly, that wasn't mentioned anywhere on the page before.

@Niharika, @ppelberg - It looks like both the AHT team and the Editing team have marked this bug as external. Does that mean that no one is going to work on it? Just curious, not pushing for this to be prioritized.

After filtering out *wiktionary ns0 and ns1, looks like 917 live pages across all wikis...

@Anomie - Any idea how many pages on Wiktionary would be affected?

It looks like @Tpt is also a maintainer of Phetools, so might be able to help.

I guess its not clear to me what exactly the decision to kill the server side component means. Are we replacing it with a different server side component? If so, how do we know the new component won't suffer from the same concerns that Graphoid has.

No, the idea is that we will no longer have any server-side component dependency. This decision is based on the fact that we don't have engineering capacity to support a dedicated server-side component. It's obviously not ideal, and may have various problems (as mentioned by @Yurik and @Yair_rand), but the alternative would be to retire the Graph extension entirely, which would be worse.

@hashar - Doesn't look like anyone else is interested in leading this session. If you're interested in leading it by yourself, please add your name under "Session Leader(s)" in the description, otherwise, I'm going to have to close it as declined.

Next week: Peter and Marshall meet to talk detail about how best to approach Getting Started and the open questions below.

@ppelberg, @MMiller_WMF - So what were the results of the discussion in August?

@hashar, @Tgr, @kostajh - Feel free to edit the description to incorporate any of these ideas if you feel they are worth discussion. At this point, though, the main thing is that we need someone to put their name under "Session Leader(s)", otherwise the session proposal will be closed on Friday. It sounds like hashar might be tentatively interested, but is looking for someone to help on the technical side of things. Anyone interested in co-leading with hashar?

@Tgr - Perhaps it is pointless.

@srishakatux, @jeropbrenda - Agreed. This seems like a nice addition to T232816. Thank you!

We still don't have an owner identified for this session. If we can't find one by Friday, the session proposal will be closed.

We still don't have an owner identified for this session. If we can't find one by Friday, the session proposal will be closed.