See https://phabricator.wikimedia.org/T342937#10073091.

It's just built-in support for dummy edits.

The script used to not block other things from loading while loading; now, while loading, I can't e.g. open my notifications.

Have to say, just having configuration through modifying JS variables would be enough for me. IMO Having the script run on history pages may start DDOSing the servers when you view 500 changes at a time or are scrolling through page history to find something.

Thank you, that makes a lot of sense.

I've made a very basic draft at the next Tech News draft.

(For clarity: It looks like Rj misclicked and meant to merge to T401273, into which they later did.

Though the border color is indeed the biggest issues, the ambox styles and many other need to change the background color as well.

Is this task simply moving that checkbox out of the drop-down menu and placing it as a slider button to the left of the menu?

@Jonesey95 Click on the "{number} changes, {number} days" dropdown with a cogwheel in its left side and check "Group results by page".

Not sure if this is where I'm supposed to give some feedback, but this looks a bit ugly, and even when under the dropdown I thought the toggle meant it would paginate results instead of... well I can't think of a better way to describe it either.

A mysterious benefactor fixed this last week. I don't even know where...

What I mentioned would need to be more than the Wikibase thing. IIRC that only synchronizes the variants if the translation for that is empty.

So sorry that I forgot to update the task status. Thanks for cleaning it up!

It does seem frustrating technically, but from a volunteer side it is an immense positive to have a good default translation that's converted between the variants. Which is why I think that the best way to move this forward is to first have some sort of technology that would be able to automatically copy updates between the variant versions.

I would not support this unless there's a bot or something that automatically copies updates between Chinese language variants. It can skip 词汇 that are labelled inline as unique to each variant.

I would like to add yet another use case for at least have one more layer of getting a parent. Currently, for Chinese localization on mediawikiwiki, because we don't have an extra layer of getParent, we often need to boilerplately use {{LC zh|lang={{{lang|}}}.

Here's an idea brought up at WP:VPI:

Note that in this case the deprecation warning indeed has to be triggered by a leftover configuration that needs to be tweaked. See the task this was marked a duplicate of.

See https://www.mediawiki.org/wiki/Manual:Interface/Sidebar#Deprecation_warning_for_Skin::appendSpecialPagesLinkIfAbsent() which I edited in yesterday, for the history of that function. The patch for review right before your comment names the function in the changelog entry that contains the same information.

(Edited since for wikis that don't receive the wmf-branch releases, the behavior will only stop in 1.45.)

Wait, that makes a lot of sense. I even thought of a blog post I saw on a developer deciding to phase out every "null" in their code while diagnosing the problem yet I didn't act on that recollection. I'll see what I can do when I wake up.

Also, after some more testing, this only happens on Firefox. Chromium seems to set default parameters that are set to null.

The VE click handlers are registered on the li element.

Plus, anecdotally it is much more common to just want the project-independent assessment. One example is the proposal to display FA or GA status in the article tagline.

Thanks!

Could someone point me towards the "public place, such as the weekly update" where this is demonstrated?

I'm not someone who has any insight for the Wikilambda code, but perhaps this is more reason to allow Wikilambda to natively handle storing integers (perhap 32-bit ones) instead of having to rely on strings?

(Patch was improved after review comments.)

Got it, makes sense.

uhhhh, is there a reason only one of these projects can be added?

I understood what it meant, (though it is more clear now) I'm just not sure if we should backport the hard deprecation, which to my understanding means removal. Also not sure if that means this is a blocker for 1.44.

I wonder if we should make the 1.44 release with the migration function and remove it in the 1.45 release? I don't see any downsides, and a more gradual transition this way would probably soften the blow.

Plus, I made the mockup very poorly, as you may see. I coded the patch so it gets appended to the bottom of the top menu instead of the weird location in the mockup. If you want to get alerted to other prominent-ish tasks, you could subscribe to Tech News!

I've submitted a patch for that as https://gerrit.wikimedia.org/r/1118212. I linked the "moving special pages link" task instead since the change isn't really part of the rethink/simplification.

Yeah, but n-recentchanges is [in the interaction menu on most wikis]

Is there precedent for using an update script we could reference?

Yep! Maybe add something about how the link will only be automatically appended until MediaWiki 1.45-wmf-whateverversionweharddeprecate is deployed though.

(FYI discussion on technical details moved to Gerrit. We currently have a working implementation that automatically appends the link to the sidebar if not present.)

Makes sense. I'm new to the MediaWiki core codebase though, so I don't really know where to put that. Could you point me to a previous example of a migration script? Thanks for your time!

The only approach I could think of (and committed) for the part on adding "Special pages" to the navigation menu changes the default value of the "sidebar" interface message. So if the patch is merge, all wikis that customize "MediaWiki:Sidebar" will simply see the "Special pages" link disappear. Thoughts? Also, does this mean User-notice should be added right now?

Is there a reason the parent task was removed? I'm sure there's a very good reason, but I'd like to see what it is.

Looks exciting! Is there a reason this is absent from Codex/Planned Components?

Yeah, LST has quite niche (but important) usecases.

Hmm, I get what you're saying now. However, while it's certainly not straightforward from the Wikitext to the HTML, I think it's fairly straightforward the other way around.
Timeshifter also suggested an approach used as an example by https://www.w3.org/WAI/tutorials/tables/caption-summary/: put the summary in a span that's linebreak below the table caption and within the table caption element. (I'm not saying we should use the <br> element used in the example for this; I'm sure CSS may accomplish the same effect.)

Despite the slightly-invalid SVG code, the SVG still renders in browser if I render its code.

Are Wikitext tables not supposed to be analogous to HTML tables? It looks like the parser renders them into an HTML table.

Sorry Izno, I missed your comment which advocated a different end result. As the summary element is also visible to sighted readers, I support the approach in the task description.

Thank you for tagging this task with good first task for Wikimedia newcomers!

I echo how much we value this work.

@mmartorana it looks like someone needs to re-vote on code review now that CI is passing

thanks! I am honored to have created essential work for y'all /hj

Yeah, I don't see it anymore.

Does commons have a list of templates to be automatically substituted by a bot?