In T362856#9749606, @Wargo wrote:

They had problems T363086 with deployment procedure and I don't know how they finalized it.

I can replicate those on Windows 11 + Edge 124, so the result seems to be independent from the OS newline convetions. Tested /tools on plwiki and both /tools and real filter on a local installation of MW 1.40.

In T363628#9750833, @suffusion_of_yellow wrote:

If that doesn't work, try using new_wikitext_pst.

I've just copied the content of Użytkownik:Swam_pl/brundopis3 to Użytkownik:Msz2001/brudnopis (examine) and the result is the same: the edit is recognized in an examine mode but not while saving.

In T362856#9749452, @Wargo wrote:

No, from 23 to 25. Last event was 18:20, deployments are on 20:00 (in Poland)

The patch that @KartikMistry mentioned was deployed on 22 April to plwiki, but it seems that it doesn't completely prevent unqualified users from publishing translations to mainspace. The edit filter for that caught two cases on 24.04. and 25.04.: https://pl.wikipedia.org/w/index.php?title=Specjalna:Rejestr_nadu%C5%BCy%C4%87&wpSearchFilter=38

I can confirm this on plwiki as well, as reported in https://pl.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne#Wyszukiwarka_si%C4%99_popsu%C5%82a (permalink).

In T362139#9724671, @matmarex wrote:

I'll be honest, I'm not sure how it's supposed to work. But I think I managed to restore how it worked.

I set up demo wikis to compare:
Before the bug: https://patchdemo.wmflabs.org/wikis/777f1587e8/w/index.php?title=Test1&action=edit&undoafter=152&undo=153
Current buggy version: https://patchdemo.wmflabs.org/wikis/1010d4fce1/w/index.php?title=Test1&action=edit&undoafter=152&undo=153
After the fix: https://patchdemo.wmflabs.org/wikis/83a92cb3f0/w/index.php?title=Test1&action=edit&undoafter=152&undo=153

If someone here feels like they understand it, I'd appreciate if you could test on those demo wikis as well.

Deployed to wiki

The change was deployed today.

Here are some direct URLs to the Undo page (the versions can get reviewed in a future, though):

• https://pl.wikipedia.org/w/index.php?title=Castel_del_Monte&action=edit&undoafter=67488563&undo=73325709&uselang=en
• https://pl.wikipedia.org/w/index.php?title=Stopa_cukrzycowa&action=edit&undoafter=73029306&undo=73325816&uselang=en
• https://pl.wikipedia.org/w/index.php?title=Polski_Kontyngent_Wojskowy_w_Rumunii&action=edit&undoafter=73004824&undo=73325826&uselang=en

It might be because of T343483: Change mechanism for altering links to Objects to not cache based on user page, and work with Parsoid

In T334940#9605163, @TheDJ wrote:

I would advise the community to look for solutions for graphs outside of the foundation (maybe through a grant or something). I personally still think that running something on toolforge and exporting to SVG which can then be uploaded, is the most flexible, easiest to realize and most usable short term way to enable rich creation tools. It creates a hard separation between security contexts and avoids any sort of fragile dependency on MediaWiki and Wikimedia. The uploading can even be automated, OAuth login and commons uploading are commonly implemented things in tools already.

@Urbanecm The SVGs are available on Commons now:

• icon: https://commons.wikimedia.org/wiki/File:Wikimania_2024_icon.svg
• wordmark: https://commons.wikimedia.org/wiki/File:Wikimania_2024_logo_black.svg
• old-style wiki logo: https://commons.wikimedia.org/wiki/File:Wikimania_2024_wiki_logo_(old_style).svg

I'll provide the SVG versions by tomorrow

The one that's used by the ResourceLoader to ensure users won't get syntactically incorrect code. The one in the editor flags no error (only some warnings and infos and none of them is around the problematic 910th line).

In T357580#9549180, @UOzurumba wrote:

There are changes to how user and site scripts load for Vector 2022 on specific wikis. The changes impacted the following Wikis: all projects with Vector legacy as the default skin, Wikivoyage, and Wikibooks.
Gadgets are not impacted, and the changes will last for the next three months. If you have been affected or want to minimize the impact on your project, see this ticket. Please coordinate and take action proactively.

There's a potentially highly visible regression for wikitables on mobile: T357589: [Regression] Wikitables has unwanted border spacing on mobile

I've just checked and it still persists:

Yeah, OpenSeaDragon looks for .prp-page-image img selector (source code) and as it cannot be found on the page in the task description, the error message is raised. (There's no <img> tag there).

In T340705#9493354, @Candalua wrote:

Some months ago I had applied many optimizations on it.wikisource using the |rights=purge syntax. However, right now the Special:Gadgets page is showing me this error: "The following right does not exist: purge". Did something change in user rights? Maybe the "purge" right does not exist anymore and I have to use something else?

In T334940#9480929, @Tim-moody wrote:

Can someone point me to the policy regarding JS gadgets?

In T334940#9474610, @Tim-moody wrote:

I would also like to see SVGs able to be embedded on wiki pages, such as the excellent charts from Our World in Data, see https://ourworldindata.org/influenza. But the key to OWID is their use of JavaScript embedded in the SVG to provide client side interactivity. I am not clear on the WMF policy on client side JavaScript, though there seem to be instances where it is permitted. Elsewhere I have suggest a collaboration with OWID developers as they are actively developing SVG functionality. But in any event adding this functionality to mediawiki seems to me highly desirable.

As an example, in the WikiProjectMed mediawiki we use the iframe that OWID serves to isolate the SVG JavaScript from the surrounding page. See https://mdwiki.org/wiki/WikiProjectMed:OWID,

Thanks a lot! Everything's fine.

Just noting that after this was implemented, on the definition page HTML comments after file name are treated as a part of the name contrary to what happened before (and they make the validation to fail). Thus I've had to "fix" two gadgets on plwiki by moving the comment: https://pl.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition&diff=prev&oldid=72407946

In T349361#9426479, @Aklapper wrote:

@Msz2001: Do you still experience this?
I cannot reproduce this anymore for pl.wikipedia.org using https://www.google.com/search?q=sejm+x+kadencji+polska+Rzeczypospolitej+site%3Apl.wikipedia.org while being on some public WiFi on some train in Germany, using Firefox 121:

The addition of oojs-ui-core.icons, oojs-ui.styles and oojs-ui.styles.indicator to render blocking CSS (not sure what is adding this but it does not appear to be gadget related and seems related to something on the page calling OutputPage::enableOOUI)

The RecentChanges filter popup is still big for me. Was it supposed to be fixed by the fix to Vector skin?

It's worth noting that mediawiki.org is also labeled as Wikipedia:

I've sent feedback to Google when I filed this task. I created this phab ticket as well, since I'm not sure if this is a problem at Google or at Wikimedia.

I have the same problem for numerous Wiktionary language variants, I've got it from wiktionary bread search

In T347907#9229994, @Quiddity wrote:

I'd like to include the context so that it might act as a memory-aid. Would something like this be accurate?

Code related to addPortletLink and #p-namespaces that was deprecated last year is now being removed. If you notice tools that should appear next to the "Discussion" tab are now missing, please tell the gadget's maintainers to see instructions in the Phabricator task.

And when is the change planned? (So that we can tweak "is now being removed" to either "is being removed [this/next] week" or similar.) Thanks.

In T347665#9210352, @dcaro wrote:

In T347665#9209846, @Msz2001 wrote:

My tool just went down ( http://vector-dark.toolforge.org/ ) - the address is reachable but browser is loading forever. And I'm unable to ssh into it (asks for password and then hangs).

It works for me now, can you retry?

I'll close this for now, there's a few things that we can improve for the next time but those will be addressed on their own tasks.

Thanks!

My tool just went down ( http://vector-dark.toolforge.org/ ) - the address is reachable but browser is loading forever. And I'm unable to ssh into it (asks for password and then hangs).

I've included a link to a sandbox that contains wikitext equivalent to the template output before any hacks in it so that the problem can still be seen and reproduced.

There's some spec here: https://www.mediawiki.org/wiki/Page_Previews/API_Specification although it doesn't cover cases like display: none or other regarding styles.

In T111565#9141088, @matmarex wrote:

In T111565#9139046, @Msz2001 wrote:

It's worth noting that mobile MediaWiki already supports collapsible class, which is almost the same as mw-collapsible in appearance.

That doesn't work for me. I don't think it's a MediaWiki feature, but it's a fairly common on-wiki customization (older than mw-collapsible).

It's worth noting that mobile MediaWiki already supports collapsible class, which is almost the same as mw-collapsible in appearance.

Hi! What's the status of this task now? Some time ago ResourceLoader modules became targetted at desktop,mobile by default and it appears that running the following line in the browser console on a mobile version works as intended:

mw.loader.using('jquery.makeCollapsible').then(() => $('.mw-collapsible').makeCollapsible());

And the dialog "Test case details" content is also title-cased. (The dialog that's invoked by the (i) icon in the test cases table for a function).

It also applies to the "Pass" / "Fail" labels regarding the test status on the function details page.