That sounds great!

If everyone's happy with how this is working now, I think this can be closed.

It looks like this is working correctly now. Closing without QA, to try to clear up the old tasks.

There do not appear to be any more occurrences of this error in the logs.

I've experimented with doing what the Math extension does, and saving the replacements in an instance variable (still doing the substitutions in onParserAfterTidy). The ParserOutput extension data isn't available in the same way, and at first I thought that was because it was a different ParserOutput object (which it is), but there seems also to be a difference in the order of execution.

Was this feature only recently enabled? Because the issue was introduced into the Schema a month ago: Featured templates: add messages, and set max/min field count.

@Tgr I'm guessing this VPS isn't used for anything is it? Shall I go ahead and delete it?

Relatedly: I've updated the 'Submit wish' button template to add the returnto parameter.

One last bit to update here: update the wish-type error message to use the new getErrorMessage() method.

I'm pretty sure I do for e.g. https://gerrit.wikimedia.org/r/admin/repos/mediawiki/extensions/RedirectManager,branches but there's no option there to delete branches. I'm a member of the group for that extension: https://gerrit.wikimedia.org/r/admin/groups/ab26ff1b0560af6014adeccaa8cdd384515142e0,members

It used to be possible for maintainers to delete branches in Gerrit, but this doesn't seem to be the case any more (or am I missing something obvious?). I was going to suggest that for Cargo it might be easiest to just manually delete the branches and then do so every six months.

The patch I have in progress is basically just going to add the proposer to the /Votes subpage, and after that it'll just be a normal vote to be removed or updated at will.

As Cargo doesn't use release branches, they could just be deleted (that would reduce confusion all around I think).

The last part of this is DonationInterface, but it's hitting an error: T407812.

difference between "Accept Suggestions" and "Submit": i want to make sure the acceptance of machine translation is intentional to ensure the quality. I can remove the "accept suggestions" button and add a warning text box instead.

That task says that it's fixed in T374616, on which task @cscott says that "further work will be tracked in T388786", so I guess the basic returning of HTML works (as it does) but perhaps not all features (like handling the recursive parse of <languages />)? I'm not sure.

Thanks @Paladox!

Good idea. There's also T270966 (relating to svgtranslate adding content when saving).

Yes it looks like the frwiki case is a fluke of the desired order happening to match up with the page ID order of those templates! Oops. Sorry about this. Thanks for checking up on it!

I think that maybe this task is related: T407101: CommunityRequests pages contain UNIQ markers when rendered with Parsoid

I think this might be similar to T289545, where it says that (in 2021) "none of the extensions deployed on the Wikimedia cluster register parser functions whose return values have the "isHTML" flag set" — so maybe {{#CommunityRequests:}} is the first.

I spoke too soon, now it can't install epubcheck.

One of the issues was that the DO IPs are blocked by Beta:

Added wikimedia and mediawiki as maintainers. Thanks for the reminder!

I don't have access to that doc.

ms-arab is now available in all three language pickers.

The OAuth tag is sufficient.

It seems that staying with ULS is fine for now.

This is done more or less, and I've updated the link in the footer to point to the Commons page.

This bug has been fixed, and it should now be possible to switch to any UI language and have it remember your choice.

This is all done now I think.

I assume page-visited doesn't need a context, but that's weird that action_source is null. It looks like it's not always null though:

That patch is included in wmf/1.45.0-wmf.22 and wmf/1.45.0-wmf.23 which are what's current on all sites, so it doesn't look like there's an issue there.

I think a content type is overkill for something that's only ever going to be a single page. I've fixed the issue with the icon_width values.

The other option here is to do it the other way around, and show the UI elements in the content language. That would mean that all elements on a page would conform to the language of the Translate selector at the top (and for wikis without Translate, it'd be the site language). There are usually more interface languages than target languages for page translations, so that'd reduce the number of people interacting with the filters etc. in their own language.

Test Case 9: Verify translation and interface message handling
Switch the interface language (e.g., to French or Hebrew).
✅❓❌⬜ AC9: Confirm that all filter labels and category names are properly localized based on the selected language.

Fixed a while ago.

@Aafi The above changes to only showing the link if the talk page already exists. Do you think this is sufficient?

Done.

The issue here is that we don't want to show all the statuses in the filter box isn't it? I mean, there's no other reason for defining excluded statuses.

That's not super elegant is it! Because we're treating 'not declined' as being just 'everything else'? I don't see how else to do it without introducing some sort of filter negation, which is going to get trickier. And does that happen when linking to the index page via a tag? Because if so, perhaps if we're linking to a tag it makes sense to list all, including declined.

When checking the "Suggest machine translation" would the text fields then get filled with the suggestions? (As a side note, it'd be good to show some visible loading state at that point.) Once the suggestions are in the text fields, what is the difference between "Accept Suggestions" and "Submit"? Or does it mean that the suggestions will be shown e.g. below each field, and the accept button will move them into the fields?

https://glam.wmcloud.org is up and running.

Thank you both! All is well now.

Re-opening to target a new wiki at https://glam.wmcloud.org.

In T402027 I'm removing the 'unknown' status. (No that that changes this task.)

There are seven status messages that are no longer used: draft, submitted, open, delivered, blocked, and archived. I'll remove these.

We talked at one point about not having the same statuses for focus areas, because some don't apply. It does seem like maybe it's only 'declined' that's definitely not going to be used for a FA though, so for now it might be simpler to just keep using the same list. (I thought it might be good to sort that out while doing this task because it'll create new i18n messages that will be translated, and we shouldn't create more than are necessary.)

Thanks!