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?

How long would this need?

1. Well @DVrandecic said it was a good idea when I proposed a tracking task
2. How do I propose a new column for the workboard then?

Still, like the Blockly task, this will probably be written from scratch (the idiom, not the online language).

Languages do not have "licenses" and can't be licensed. The official LabVIEW is proprietary, but that doesn't prevent 3rd party projects like https://github.com/mefistotelis/pylabview. Usually reimplementers just code their own implementation from scratch, which is what EV3 did.

Since this doesn't work completely yet I'm reopening it for now

For me, on selecting V10 from anything, there's an empty Skin preferences section. When I switch to another radio button after selecting v10, there is no Skin preferences section at all (as you demonstrate in your first screenshot), even though V22 has a limited width mode option. When I switch to selecting V22 from any option that isn't V10, both checkboxes are visible.

If V22 responsive mode isn't completely ready yet, shouldn't it be declared as *not* responsive for now?

Yep, fixed!

The interlingual Wikisource's login still doesn't work.

Hmm, logging in works now.

I'm pretty sure I haven't enabled any gadgets on Wikisource.

At least on en.wikisource, I only have 1 session ID though. These are present even when not logged in:

Just another license in the license selector except after selecting, you'll get a text field or nested selector for the Wikimedia Wiki the screenshot is from

I know how to. Which cookies should I check for?

Thanks! I presume no one wants another option for screenshots of Wikimedia sites?

Hey @Urbanecm_WMF , is there any progress on this?

I also sometimes get it on Wikipedia by typing in things before JavaScript loads (you get OpenSearch) and then continue typing after V22 search loads. Both boxes appear

I can confirm on Wikipedia. Does anyone have an update?