@MMiller_WMF - The audit (T229887) has been abandoned, so please feel free to move ahead accordingly.

Boldly marking as resolved since it seems unlikely we are going to get more detailed information than DLynch's audit above (T229887#5819921), especially since the task has been unassigned for the past 8 months.

@ppelberg - I think the cause of the confusing order (and T189569) is that some of those dialogs are created by the GettingStarted extension and some are created by VisualEditor itself, and no one ever evaluated the interplay between them (AFAIK). Since no one is maintaining GettingStarted, I personally favor decomissioning it entirely (T235752).

@phuedx - Since I can't get any traction with the Growth team on this, any chance you'd like to own it?

@Whatamidoing-WMF - It looks like the Library of Congress is using the same "weird" punctuation and capitalization as WorldCat:

@TheDJ @Tgr - It seems that most of the work currently being done in relation to this is at T259617 and associated subtasks. Not sure why those aren't connected here though.

@eranroz - I implemented a work-around for RefToolbar. You can probably use a similar work-around for Checkty: https://en.wikipedia.org/w/index.php?title=MediaWiki%3ARefToolbar.js&type=revision&diff=977779611&oldid=972381502.

Reopening per @eranroz's comment above. I also confirmed that this bug occurs with RefToolbar on English Wikipedia (which also uses Citoid). We should implement a fix within the Citoid service itself, rather than just in VE.

@Esanders - Thanks for the clarification. That is very helpful information.

I'd like to hear more thoughts about https://ko.wikipedia.org/w/index.php?oldid=27478403&diff=prev&diffmode=source and https://en.wikipedia.org/w/index.php?oldid=977124090&diff=prev. For me, the most annoying feature/bug of VE is its tendency to add unexpected <nowiki> tags (although its much better than it used to be). If this problem also occurs with DiscussionTools, I imagine it will affect community buy-in for the feature. Is the addition of <nowiki> tags strictly necessary? When is such addition considered "correct" or "incorrect"? Is it possible to fully eliminate "incorrect" <nowiki> additions or is the problem too complex to decisively resolve? Sorry for my ignorance on this and if it's already been discussed elsewhere.

@eprodromou - We already have an API for retrieving the description, whether local or central (action=query&prop=description). Why would we create a separate API just for local descriptions? And what does "managing" local descriptions mean? The editing component seems to be covered in T257944. It would be great if this task explained the context, motivation, and end result desired, as right now this task is completely opaque to an outsider.

@Charlotte - I don't see that information reflected in Phabricator. Right now T257944 is the "Feature Requests to Review" column of the Platform Engineering board. That doesn't sound like it's ready to be worked on. But maybe Evan just hasn't moved it to a more appropriate column yet. @eprodromou, can you clarify?

I think the new editing API may take a while to actually materialize (as there are higher priorities for Core Platform at the moment). Would it be possible to just disable description editing on English Wikipedia on Android in the meantime?

@Dbrant - I'm not sure I understand the connection. Search shouldn't be dependent on editing.

@Dbrant - Any insights into why this is "blocked/waiting"? Anything I can do to help?

@marcella @MMiller_WMF - I really don't want to micro-manage here, but we've been kicking this bug around for 2 and a half years now. Any chance we could slide it in some time soon? It creates a poor experience for every new editor on our projects :(

It looks like this was previously discussed in T252891.

Reopening per T257091

@ssastry - If they're the same thing, definitely feel free to merge.

@ssastry - Would you be so kind as to flesh out this ticket for Platform Engineering? Thanks!

The main issue related to this (T239220) has been resolved. Will reopen if T250084 requires any follow-up from Platform.

If y'all end up needing follow-up support from Analytics or any other teams in the Technology Department, please let me know.

Hmm, it still seems to be broken.

It looks like most parser functions, such as {{urlencode}}, are not supported on the client-side, so there's nothing else to do here.

Thanks.

It seems that if the local message includes {{urlencode:$1}}, it breaks the parsing. I went ahead and removed that part of the message on Commons for now.

Interestingly, I can't reproduce this bug locally, however.

@Etonkovidova - The difference is that someone locally overwrote MediaWiki:File-deleted-duplicate on https://commons.wikimedia.beta.wmflabs.org/. You did successfully reproduce the bug though. In both cases, the message is failing to be parsed.

Should this work apply to these watchstars? (Perhaps it already does.)

Absolutely no feature development is to be done for StructuredDiscussions (Flow), only bug fixes, since StructuredDiscussions is eventually going to be deprecated in favor of the Editing Team's new Talk page features. Recommend decline.

It's not clear to me that:

1. There is a way to do this that isn't going to be confusing to most users.
2. That the use cases for the raw watchlist even necessitates handling expiries.

The purpose of the raw watchlist interface is bulk adding or bulk removing pages from your watchlist. Neither of those uses would be affected by just leaving the interface how it is. Bulk removing and then bulk restoring pages with expiries is a vanishingly small edge case and I don't think it would make sense to complicate the interface for that specific case. The only use case that I think might justify complicating the interface is bulk addition of pages with expirations. But even then, I have to wonder if the trade-off of potentially confusing users with a novel mark-up system is worth the benefit.

@Mvolz - Now that the code is merged locally, what happens next? Does someone need to deploy the new version to the production servers?

@akosiaris - The Community Tech team needs basically the same thing that was set up for the Language team, just for a different Google Cloud Services API. Do you think it would make sense for them to both share the same proxy service or should they be handled as separate services?

@Dbrant - If you're not working on this, is it OK if I remove you as the assignee?

@eprodromou - I'm a bit confused. Usually untagging a team means you are disclaiming responsibility for it, not claiming responsibility for it.

@dbarratt - My idea would probably be controversial. Parsing the blockreason is probably easier.

@DED - @calbon is going to be heading up the production integration (T259471), in collaboration with @Niharika (as the product owner), so please coordinate with him as well.

@Iniquity - Your continued arguments here are inappropriate and disruptive. Please stop. We have already agreed to implement this change at the request of the English Wikipedia community. If you have concerns about the merits of this change, please take them to that community and present your case there.

There is not about local consensus of enwiki, they can do whatever they want, it's about how the developers and the fond implement the integration with wikidata and between all projects.

Nothing will change regarding the Wikidata integration for other projects (besides English Wikipedia).

@Dbrant @Tgr - Is this something that the Core Platform Team can help with or is it being handled already within the Product department? If it's already being handled, what is the estimated timeframe? In other words, when do you expect this to no longer block T256817?

@DED - So how close is this task to "done"? Unfortunately, I can't parse the last remaining acceptance criteria: "Re-implemented most of the code now but missing training data and 'embedding' pipeline for users." Is this ready for Platform Engineering to start building an API around?

Seen again on 1.36.0-wmf.2 on Commons:

MWException from line 905 of /srv/mediawiki/php-1.36.0-wmf.2/includes/MovePage.php: Failed to create null revision while moving page ID 92702621 to File:Ancienne_église_de_Laborde_(Hautes-Pyrénées)_2.jpg

Thanks for the feedback @akosiaris. I've conveyed it to our contact at YouTube. I also mentioned that binding Citoid to a static IP address would probably increase the chances of it being blocked from other websites.

Can we please stop rehashing the RFC here? If there is difference of opinion on the merits of this change, please seek consensus on Wikipedia, not here. Arguing here only wastes the time of everyone involved.