In T405861#11379359, @Bawolff wrote:

To be clear, the static parts of vega only. Vega had a lot of dynamic interactive features (which nobody ever used) which isn't viable with this method. Even things like tooltips are hard. Additionally some data sources are not available from lua (e.g. i think vega let you make sparql queries)

In T52896#11361583, @Sarefo wrote:

...
Meanwhile, to make sure, code like this *will* work with VE, right?

<references>
<ref name="miller2005">…</ref>
<ref name="brown2006">…</ref>
</references>

if so, I'll use these for now. doesn't seem much worse than {{reflist}}, and much better than the scourge that is inline refs.

✅ Visit Special:Preferences#mw-prefsection-editing and ensure the automatic topic subscription setting is enabled within the Discussion pages section
✅ Using each of the Editing interfaces listed above, do the following:
❌ Start a new discussion and verify that after doing so you, you have been automatically subscribed to the new discussion you just started

I seem to have more then 500 but almost all of them from core, only 20 from gadgets.

{
let all = Object.keys(mw.user.options.values);
let user = all.filter(v=>v.startsWith('userjs'));
console.log({all, user})
}

In T334372#11310608, @SD0001 wrote:

In T334372#11310022, @Nux wrote:

I don't understand why T405861 (Lua implementation) was merged and not this task. The effects for readers are the same, but T405861 only works in Lua (so less use cases for creators). I don't understand this decision.

Lua can be used anywhere wiki markup can be used, so I don't see how use cases are lesser. T405861 also has additional benefits described in its task description.

I don't understand why T405861 (Lua implementation) was merged and not this task. The effects for readers are the same, but T405861 only works in Lua (so less use cases for creators). I don't understand this decision.

I did a quick PoC to replace Pie chart with SVG. This is a no go unfortunately.

The idea was to enable logging on plwikisource first, and then possibly enable it across all of Wikisource later, depending on the volume of errors. I'm still an interface admin on Wikisource, so I can still help get this going :)

In T334372#11215860, @SD0001 wrote:

In T334372#11215316, @Nux wrote:

BTW. Still waiting for the merge. I think the patch is ready for action :)

Patches with merge conflicts can't be merged.

Please note using div+css to create charts (e.g. https://en.wikipedia.org/wiki/Template:Pie_chart) may be considered a hack instead of a proper solution - the "chart" is not a proper image you can download.

In T200632#11213192, @stjn wrote:

While it would be better than nothing, it is not really a ‘compromise approach’ since one of the best uses for CSS variables is to simplify colour assignment. I don’t think there’s anything wrong with the idea, though.

One part of this would be: are there any settings we shouldn't allow folks to override? Things that would allow admins to collect data about users (e.g., $wgCheckUserClientHintsEnabled)—this is the one I know about, but are there others?

Oh, so that was because of {{r}}... Then yes, that does seem to work now. Thanks for the rapid fix :)

We have two reports of multiple removals or refs defined in the reference tag. I assume this is the same problem?

In T320322#11165837, @Tacsipacsi wrote:

@Volker_E I’m not sure if --color-main is a good name: it’s likely to clash with software-defined variables. I’d treat standard prefixes like --color-, --background- etc. as reserved, which should not be used in on-wiki definitions (usage is of course fine).

I think "copyvio" might be used sometimes for images, but rarely. We have a tool for adding common phrases to summary that adds NPA with a link, so that would be the most popular.

On plwiki, we need this for reviews so that we can clearly identify who is making changes and avoid misidentification (see more details in T402213).

I mentioned this already on the cloud mailing list, but please remeber to update the documentation if you are making database changes.

Also cannot reproduce now. The full URL was something like this:
https://pl.wikipedia.org/wiki/Dyskusja%20wikipedysty:~2025-19895-4?action=edit&section=new&dtenable=0&newsectionname=%5Bhttps%3A%2F%2Fpl.wikipedia.org%2Fw%2Findex.php%3Ftitle%3DWikipedia%3AZg%25C5%2582o%25C5%259B_b%25C5%2582%25C4%2585d_w_artykule%26diff%3Dprev%26oldid%3D77205824%23Felix_Hausdorff%20Ad%3AFelix%20Hausdorff%5D
(long link has parameters for auto-text added by a gadget)

In T402213#11105920, @Niharika wrote:

@Nux Hello! I appreciate you taking the time to file this ticket.

I should be able to tell if this is the same user. Some ways to do that:

• Reveal IPs in history preview (screen below).

Can you explain this a bit more? I'm not sure I understand this suggestion.

Sure. If it works, it works. It's just that I noticed there are some browsers that don't define document.body (browsers connecting to wiki), so having a weird IntersectionObserver impl wouldn't surprise me anymore :)

What if entries can actually be empty in some Tizen/Bravia TVs? That would make both closestNegativeEntry and closestPositiveEntry undefined at the end.

Hi, would it be possible to enable this on Wikidata? The Wikidata item interface is not very flexible at the moment, but it is workable with some CSS (I made a workable CSS for myself). The ability to use Vector would provide some options for editing properties. As you might know already – It's a highly demanded feature: https://meta.m.wikimedia.org/wiki/Community_Wishlist_Survey_2023/Wikidata/Adding_statements_on_mobile_devices

Note that, starting from 28 June 2025 (so just last week), services such as Wikipedia I think are formally required to comply with the European Accessibility Act (EAA):
https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/union-equality-strategy-rights-persons-disabilities-2021-2030/european-accessibility-act_en

In T397887#10953063, @Wargo wrote:

FlaggedRevs styles not loading.

Note that template data loads quite fast. You can test on enwiki, as previous behavior still works there (no favourites yet).

yeh the only downside is dark mode support which wouldn't be compatible with a rendered SVG: https://patchdemo.wmcloud.org/wikis/f78c465586/wiki/Charts?vectornightmode=1

In T376845#10638932, @Ferdi2005 wrote:

This would be very useful. In articles with infobox templates e.g. https://it.wikipedia.org/wiki/Nienburg/Weser, graphs tend to "clear" instead of "floating" next to the infobox.

Current behaviour (on Desktop):	Expected behaviour:

Next to the infobox template, not under it leaving blank space.

Hm... Scaling should work fine in an <img> tag. Just generate the SVG and encode it as a data URI. Here's a PoC:
https://patchdemo.wmcloud.org/wikis/f78c465586/wiki/Charts

{{#chart:Global wind power production.chart|title=hide|legend=hide}}

Sounds good to me.

This only affect 3rd party tools like AWB, not Edge browser which is based on Chromium. Also, Windows 10 will be EOL later this year.

We had a discussion about using some Data:*.chart as a template—using it with very different data (many *.tab) on many pages. One of the concerns was that someone might add a title and break many pages. Not sure if this is a justified fear; I guess we just don't know how it will work from the human side of things.

Oh. I was told T393306 might be related.

In T394879#10853587, @thcipriani wrote:

As I lost one of my Patchdemo installations, I think it would be great to have an extra section on backups.

What do you mean lost? Like it was deleted?

Added some examples and info to patch demo.

• introduction to this SVG patch
• short SVGs embedded in wikitext
• Template and modules tests by SD0001

While the placement of the link is not ideal, it is what it is for now. To understand why it needs to be there, please read a transcript of the video here: T390443#10711208 (in short: a blind person can—and probably will—start with the h1 to make sure where they are). You can also watch a full test or watch just the part about trying to read an article.

I don’t think the accessibility issue is resolved by a skip link in any meaningful way, as T13555 details. The issue is that the header is wrongfully announced as [Full title] edytuj if you try to use it for navigation. Now, after your edit, it is in most senses even worse, since that skip link is also added to the header, so the header text is now announced as [Full title] Przejdź do treści edytuj. The thing that needs to be fixed is the edit link (as well as any other elements) being inside <h1>. The problem is that while Vector 2022 allows to fix that potentially, other skins do not.

Added a skip link before the edit link (T390482). That should cover WCAG problems arising from a link in header (or at least some of it) and also resolve some other issues.

For now on plwiki we used:

<a class="mw-jump-link" href="#mw-content-text">

Please let me know if this is OK to use that class. Seems to work fine:

There is also a 2nd one in Poland if that helps:
https://www.wikidata.org/w/index.php?title=Q122261336&action=history

Thank you for your support. I did keep in mind the need to make this feature as secure as possible and opted for a sandboxed mode that, by design, doesn't run any kind of scripts (see: SVG as image security). So it should both be secure and future friendly (as browsers evolve).

It seems VE doesn't work in Minerva on current version and I did switch main user in previous to Minerva (hence probably why it might not have worked for cscott).

Latest demo (minus some cleanup):
https://patchdemo.wmcloud.org/wikis/32e7a844e0/wiki/Talk:Main_Page

Contributions page has a call-to-action link pointing to Special:Wantedpages as of late.

The videos are available again. The video is in Polish. Rough transcript in previous comment: #10711208. I forgot some details, but that's probably still a good summary. Some extra notes:

There is another solution. I just remembered that, instead of skip links, MediaWiki could add off-screen headers. This was said to be helpful during the review of my company's product. You can see an example of off-screen content using this link:
https://libra.lib.mol.pl/?debug=true
(click on "Pokaż/schowaj offscreen")

There is also a problem if user skips to H1 and then try to find search results.

It is unclear from this statement what the problem is ? This seems an assumption about page layout, that while often true, is simply NOT a rule that can and should be relied upon.

Works great on plwiki too. Thank you.

That would mean 3-10 cookies, and avoid setting up separate sessions on 150 websites.

This is pretty much what happens. I'm not sure where you got the idea that 150 websites are involved.

I want to highlight a point made by @Masti after the presentation — we might consider recommending a different skin for screen reader users (not sure if that could be done via a hidden button that triggers the switch?). That would probably be a separate task, and maybe only worth pursuing if skip links in the default skin (Vector 2022) turn out to be insufficient, infeasible, or otherwise problematic.

It seems like some people use "inline SVG" to refer to an <img> tag with an SVG data URL in the src attribute, but that's not the usual meaning of "inline SVG."

Note that the way this box is laid out, it would be hard to control it. I made some attempts using grid, but that didn't work well. Once I let go and just used a good old float, it just works. The text flows nicely, and you don't need to truncate it. See my layout proposal:

As suggested by Tim Starling in the code review, I added more properties:

• contain-intrinsic-* (block-size, inline-size) https://drafts.csswg.org/css-sizing-4/#intrinsic-size-override
• min-intrinsic-sizing property https://drafts.csswg.org/css-sizing-4/#intrinsic-contribution-override

Confirmed on archived ACE version:
https://web.archive.org/web/20240324151011/https://ace.c9.io/

Hi. Is there a sane way to wait for the initialization of ve.init.mw.targetFactory? I did do an insane ;) way of waiting for the object in intervals. It works, but would prefer to use something else.