Got it, makes sense.

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

I understood what it meant, 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?

Thanks for the review.

Why would we consider how Baidu indexes us then?

It may be that we want {{#aside}} to put content into a separate ParserOutput section, like <indicator> does, so that skins can combine the aside content and the article content in more flexible ways. Assuming that the best way to style asides in article content is to embed an <aside> HTML element literally within the article text is not, I feel, a particularly helpful place to start.

Baidu (our second largest referring search engine)

Congrats! Is there a way to test this documented anywhere?

Well, Bing still has the old links. I thought that meant other search engines will also do the old links but that seems false and I agree that it's probably not worth the extra effort.

Not all methods seem to redirect properly. For example, the redirect for https://doc.wikimedia.org/oojs/master/#!/api/OO-method-inheritClass doesn't have the necessary dot in front.

I agree with JWBTH. The new color has 20% less contrast on the subtitle text. They don't provide adequate contrast.

This seems deployed on the English Wikipedia; integration has been put into the Talk quote block template.

I'm assuming the QA for single-line ;bar:rry also highlights both correctly?

Agreed that replacement shouldn't be that much work. We can check how https://en.wikipedia.org/wiki/Template:! was migrated.

Huh, that was easier than I thought it would be. Thanks!

That does seem like a problem. So maybe another QA would be logs.

• sending abusive messages to individuals
• phishing
• spam

Note that proper usage would be

;bar
:rry

or ;bar:rry, as the bolded is the term and the indented is the definition. I don't think things would change though, and all of these cases should be highlighted.

I wonder what happens if we don't move the article.

1. In my opinion, making the container spacing consistent is enough and really good!
2. Should we be standardizing the structures a bit?

Graphs aren't core to that either. I have to agree that it's not core, but it's still important functionality the WMF should prioritize.

Good point. I feel like the blue, prominent drop-down with "Languages" in the title is prominent enough, though.

I doubt that these wikis have never used the English Wikipedia.

Settings > Safari > Advanced > Website Data > Swipe websites you want to clear to the left

Band-aids are much better than nothing at this point. JS is a similar security risk and restricting it is what we did.

Hmm. Without a given reason to decline, the reject isn't very convincing to me. The only reason against that I can see in that thread is an (unfounded?) distrust in intadmins being able to respond timely, and a pretty good concern about intadmins not necessarily knowing about graphs, which could be solved with making the small group template editors instead of intadmins.

the page layout has been destroyed, and there is now a huge and distracting sidebar on the left-hand side, which then disappears entirely if I hide it, and can no longer access it.

Seems good! Doesn't seem like it shipped on enwiki tho

Same on Twitter