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

Hmm... thanks. Maybe use the proposal to restrict it to intadmins? The vulnerability is similar to the default JS stuff, and I don't see what TheDJ means with his concerns. If we've already decided to shut down the editing activity for JS stuff, why not use that against this vulnerability?

I agree with Ppperry and Michgrig. We don't need to do everything at once. Right now, it'd probably enough to have scripting be sanitized, Vega updated to the latest, while work on a long-term solution is prioritized.

What's the status of this? It's been two months and a half without any updates or public progress done.

In T357770#9552670, @JScherer-WMF wrote:

All of this research (read the report on wiki) and community participatory design (see the analysis) led to the follow design strategies:

The improved density is way worse for reading and makes it uncomfortable. I'm pretty sure the prototyping was only done on desktop with no account for the mobile experience.

The bell icon is quite far from a square. I'm not sure what you mean.

The zebra feature flag seems removed now.

If possible, maybe if the user’s set language has a corresponding variant-something, set it if possible and expose it in preferences?

That we fix the icon first while the beta feature is being worked on. From my end it doesn't seem like there were much changes to the beta feature since it shipped.

@Jdlrobson I presume this isn't stalled now that the Accessibility prototype is finished.

@Poslovitch https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2023-10-25 has information on why JS and Python are run on WASM.

Thanks!

Also, does that languages sidebar even apply to Wikifunctions? See https://www.wikifunctions.org/view/en/Z10012?useskin=monobook . Languages seem to be always inside the page content, never in the sidebar.

Should this also be done for MediaWikiWiki?

It looks like we need someone with a Wikitech account to edit the Backports Deployments page on Wikitech.

I only know that @DVrandecic is. Anyways it’s what was suggested when I created a tracking task.

See T354233

It appeared several times on Wikipedia recently

Problem is the -enabled and -disabled suffixes are associated with binary preferences... the main menu and the page tools are either pinned or they aren't.

Well, it only happened a couple times in one day. I've never encountered it since then. Maybe something in between accidentally fixed it.

This is probably present in pretty much every wiki with V22 except Wikipedia, at least MediaWiki also has it. Is the languages dropdown in Vector 2022's code or just a hack for all Wikipedia wikis?