In T341421#8999701, @SD0001 wrote:

It's because Twinkle's gadget definition excludes it from minerva skin. So any pref changes made in minerva skin will reset preferences of non-minerva gadgets to the default value.

This is certainly a bug, though I'm not sure if it always has been the case or there's been some regression in MediaWiki-Core-Preferences. In case of the former, any fix would be closely linked to T65532.

@Jdlrobson is it possible work on this task caused the issue in T341421 ? The advice here to set all skins except Minerva is actually causing problems.

In T312587#9100232, @ppelberg wrote:

Demo: https://patchdemo.wmflabs.org/wikis/0250205d37/wiki/Douglas%20Adams?mobileaction=toggle_view_mobile#/editor/0

@Esanders: this is looking good. Two questions...

1. Can we please make the "Desired adjustment" documented below?
2. Currently, how long after seeing a mobile edit notice on a page would people see that same edit notice on that same page again? This question is related to "Open question 2." in the task description.

In T312587#9080840, @Esanders wrote:

For reference, EditNoticesOnMobile is enabled on the following wikis (source: https://global-search.toolforge.org/?q=EditNoticesOnMobile&namespaces=2%2C4%2C8&title=%28Gadgets-definition%29 )

• bn.wikipedia (not enabled by default)
• ilo.wikipedia
• pt.wikinews
• shn.wikipedia
• tum.wikipedia
• en.wikipedia

Of these, only bn.wikipedia doesn't have it enabled by default.

In T343131#9079493, @Ladsgroup wrote:

In T343131#9079397, @AlexisJazz wrote:

From what I understand one of the goals here is to make Wikidata links non-external. VRT could be filtered by category I think, besides, there are probably many links to https://ticket.wikimedia.org as well so that's another likely target for interwiki.

There is already an interwiki for ticket.wikimedia.org: https://meta.wikimedia.org/wiki/Interwiki_map

In T343131#9077240, @Ladsgroup wrote:

In T343131#9076776, @LucasWerkmeister wrote:

In T343131#9076323, @AlexisJazz wrote:

Just for reference and general understanding, can someone explain why external links are stored in a database?

To support Special:LinkSearch and the corresponding API.

Yup, to expand what Lucas said, Special LinkSearch is useful to find cases of abuse and spam, figure out where a certain link is used or a domain is linked to.

There is also a rather niche usecase for externallinks too: it stores current external links of a page, when someone is trying to edit, it checks the links in the new parsed page and compares its links with the database and realizes what links have been added and what links have been removed (instead of parsing the page twice), and sends that information to enable captcha if needed, sends it to abuse filter, and check against spam blocked lists (to avoid blocking edits that don't add a link, just happen to be done in a page that already have one).

Looking at the usecases, it doesn't really make sense to store large-scale links in templates to be external links, I don't think any time soon we would want to add dx.doi.org to the spam list.

I'm not sure if Special:LinkSearch is also relevant (or as relevant) on Commons. Spam and abuse on Wikipedia is different from spam and abuse on Commons. To the degree it's needed, insource: often does the trick.

Just for reference and general understanding, can someone explain why external links are stored in a database?

In T343131#9062308, @LucasWerkmeister wrote:

I suspect a lot of external links come from {{Authority control}}; if we enhance Module:Authority control/conf (and the main module) to support something like an interwiki_format in addition to a URL_format, that might remove a lot of external links. (Some of the URLs in that config have query parameters, so they can’t easily be converted, but many of them should be doable, including ISBN-13, VIAF, GND, ISSN, OCLC/WorldCat…)

In T343131#9061982, @Ladsgroup wrote:

Regarding externallinks. Here are most linked domains: P49955

There are 135M links to creativecommons.org (I guess licenses). If they change to interwiki link (CreativeCommons exists in interwiki map maybe we should introduce cc). That would remove potentially one quarter of the whole extlinks. They are coming from Template:Cc-pd-mark-footer and stuff like MediaWiki:Wm-license-cc-pd-mark-link which are not too easy to fix but not too complicated either.

In T343131#9058592, @Ladsgroup wrote:

In T343131#9057240, @AlexisJazz wrote:

In T343131#9057137, @LucasWerkmeister wrote:

Let me ask a slightly different question, then: is there a “cheaper” way to mark / tag a set of pages than with a tracking category? (I’m assuming that use cases like FlickreviewR can in principle be adjusted to a different mechanism, as long as it’s still possible to efficiently list all the marked / tagged pages via e.g. the Toolforge replicas.)

And CirrusSearch. Using hastemplate: is sometimes an option but less precise. In case of FlickreviewR, hastemplate: wouldn't distinguish between failed reviews and successful reviews, and problems can arise when template redirects are used.

If you ask me, this is a good usecase for structured data and then doing the reporting in WCQS. I remember even in 2015 when the discussion for SDoC was starting, one prominent usecase was to keep track of licensing, authors, etc. (that's why people built mrmetadata). I don't know how far WCQS is from being operational.

You mean https://commons-query.wikimedia.org/ ? (Wikimedia Commons Query Service)

In T343131#9057137, @LucasWerkmeister wrote:

Let me ask a slightly different question, then: is there a “cheaper” way to mark / tag a set of pages than with a tracking category? (I’m assuming that use cases like FlickreviewR can in principle be adjusted to a different mechanism, as long as it’s still possible to efficiently list all the marked / tagged pages via e.g. the Toolforge replicas.)

Copy pasting my comment from https://commons.wikimedia.org/wiki/Template_talk:FlickreviewR :

@nskaggs I agree, I designed GUS2wiki to allow multiple people to run it. (it detects if the page has been updated recently and skips it in that case) I also agree about a human as the primary runner being problematic, but whatcha gonna do.

In T341421#8999824, @Yahya wrote:

Removed |skins=vector,vector-2022,monobook,timeless,modern,cologne blue for now.

The machine I used for GUS2wiki been shut down. I try to remember to run gus2wiki on my daily driver every once in a while. It's not ideal.

Dunno how but it works again.

The certificate for upload.wikimedia.beta.wmflabs.org expired on May 17, 2023.

I've been running GUS2Wiki since July 2022. I think I'll have to shut this down at some point as I'm trying to phase out my 24/7 boxes. The next two weeks it'll be fine I think. The next month? Not sure. Next two months? Less sure.

Affects at least enwikt, nlwikt, enwiki, enwikivoyage, nlwiki, dewiki, dewikisource, mediawikiwiki, metawiki and foundationwiki. Probably just everything.

I just received one trying to look up https://en.wiktionary.org/wiki/stuff. Not reproducible it seems.

"I'm not sure how widespread this error is going to be"

I provided FF68 as an example for reproduction, as can be seen on caniuse most browsers started supporting this about a year ago so FF83 should be affected too. (and IE, Opera Mini, UC browser for Android, QQ browser and KaiOS browser don't support it either according to caniuse) I don't know how many people use a browser that doesn't support this feature.

The message has changed:

As this will never happen anyway, one less open ticket..

In T100974#7586986, @Tgr wrote:

Is there any wiki where it's acceptable to block a good-faith user without any kind of talk page message?

Personally, I'd much rather see functionality to make sending such messages easy.

"If someone could purge.. that should fix it"

e.g. in a cookie

Can someone do the thing again? It expired today.

YouTube would be able to detect that and automatically serve up whichever format is hardware-decoding supported on the user's machine - it doesn't appear to do that... but that's assuming that they would do that. :) )

YouTube is Google, so they have an incentive to push VP9/AV1.

It would be interesting to try and figure out the current capability set that's out there..

There's also https://store.steampowered.com/hwsurvey which is obviously limited to Steam users and desktop, but can provide some level of insight anyway.

(Note that the reason we're not on h.264 is the patent licensing requirement; until that gets resolved -- either by waiting until 2028 for the patents to expire or overturning the 2014 Commons RFC and reinterpreting or changing the foundation's open file formats policy -- we are stuck working around it with other formats.)

Based on https://meta.wikimedia.org/wiki/Have_the_patents_for_MPEG-4_Visual_expired_yet%3F I'm pretty sure MPEG-4 Visual (which is NOT h.264) should be fair game by now. (but we should ask legal to be certain) The Philips patent should be irrelevant (likely optional to implement in decoders and decoders are the user's problem), but any MPEG-4 rollout wouldn't happen before 7 December even if you started today, I think. MPEG-4 Visual works in an MP4 container and IIRC that worked well on Apple devices. (the primary problematic platform for this) And even software decoding is cheap as chips as it's 20+ years old. I thought there was an existing ticket for that, though I can't find it. (pretty sure brion posted some test files in it, maybe he remembers)

Not really, because if {{DISPLAYTITLE:}} is used, it replaces those extra elements.

So you could ditch .mw-page-title-namespace,.mw-page-title-separator, and replace .mw-page-title-main with a <span class="mw-page-title-displaytitle">new title</span>?

I think this is the correct behavior on our side

No chance you could just update .mw-page-title-namespace,.mw-page-title-separator,.mw-page-title-main?

Should work fine now.

OOOOOOOH now I see what matmarex was going on about when they said discussion activity had to be appended to the header element. (T314714)

Note: I just noticed my talk page has 365 days left on my watchlist. Did someone double the limit? (if so, thank you!)

https://en.wikipedia.org/wiki/MediaWiki_talk:Gadget-EditNoticesOnMobile.js#Edit_request_22_September_2022 should solve it.

I'll look at it. This would indeed be an issue with browsers not supporting ES6. ENOM was never tested on ES5 actually, but with any luck Object.values is the only problem. I already wrote ES5 implementations of several ES6 functions at https://en.wikipedia.org/wiki/User:Alexis_Jazz/Factotum-IE11.js which includes Object.values, so a little copy-paste should solve it.

"because it didn't work with the collapsible sections in MobileFrontend"

anoneditwarning != editnotice

"What is the broader use case? Why does a person want the site to tell them when they were last there?"

If there had been errors I would have probably mentioned them. There are indeed no userjs- options in the saved copy.

In T316177#8199226, @DLynch wrote:

How about the other way around? Have your solution read mw.user.options.get('gadget-EditNoticesOnMobile') and disable itself? (only works if/when/where EditNoticesOnMobile is available as a gadget though)

If we're supporting gadget replacements at all for this feature, which we are, I'd rather let our version (which is inherently going to be distributed to all wikis because it's inside VE) be disabled by many gadgets rather than us needing to explicitly update it to support any other gadgets that come along. E.g. some wiki might want their own implementation rather than ours or yours, or someone who intensely dislikes edit notices could make a gadget that just disables the core implementation without replacing it...

In T124101#7314869, @AlexisJazz wrote:

@MarkTraceur @CBogen @Tgr can someone investigate https://upload.wikimedia.org/wikipedia/en/d/de/Logo_of_the_International_Practical_Shooting_Confederation.png ? This one's interesting because it's both recent and the only revision (before my overwrite) went missing.

Right. How about the other way around? Have your solution read mw.user.options.get('gadget-EditNoticesOnMobile') and disable itself? (only works if/when/where EditNoticesOnMobile is available as a gadget though)

"What code would need to be added to EditNoticesOnMobile.js suppress the upstream mobile edit notice implementation should volunteers at en.wiki to do this?"

Vector classic/Timeless/Monobook only.

All Wikipedias with >300 active users and all sister projects of those (Wikibooks, Wiktionary, etc) are now tracked on https://meta.wikimedia.org/wiki/User:Alexis_Jazz/GUS2Wiki.json.

Never mind, the additional API call turned out to be useful to restrict how often the page is updated. So no longer an issue for me.

Can you provide more examples of the bad data from affected revisions? The –; at the start feels suspect to me, could it be a delimiter that isn't supposed to be there?

In T311308#8113569, @Umherirrender wrote:

In T311308#8026100, @AlexisJazz wrote:

I'm thinking maybe this is a kind of edit conflict, my script changes two different preferences at practically the same time. I wouldn't expect an issue since it's not the same preference, but maybe it's an issue anyway.

Point 1:
The preferences are handled as one. To change one preference all preferences of the userid are read from the database, the change is applied to that data and the according changes on the database are done with DELETE + INSERT. It seems the global preferences is using REPLACE + needed DELETE, not sure if that makes different on locking.

Point 2:
According to the Etiquete https://www.mediawiki.org/wiki/API:Etiquette avoid parallel requests, just combine both in one query to improve performance

Also for the record, I've provided a smaller and simpler mw.deflate alternative in T312720#8098113 as well as its mw.inflate counterpart.

First of all, I wouldn't say anything would be censored. The images will still be there in the articles themselves.

You have a personal and purely subjective cultural hang up about sex. Ok, fine. However it would be culturally imperialistic for us to impose your opinions of "offensiveness" on the world, while denying or denigrating the equally subjective and equally cultural and equally legitimate concerns of people demanding that Images of Muhammad be removed. And then there are the equally subjective and equally cultural and equally valid demands to censor any image of any woman-not-wearing-a-burka.

Due to ongoing issues with the hacks to work around T313140 the second wave has been temporarily put on hold. The issues should be fixed in my userspace version, but we somehow have no testers for the userspace version and after matmarex notifying me of ENOM accidentally (and unintentionally) now fixing T313140 globally I'm no longer confident enough to rely on my own testing before asking for the MediaWiki: version to be synchronized with the userspace version.

Obviously nothing actually relies on that as this only affects windows which have a symbolic size specified, so any such window is already known to become windowed on a large enough screen.

For some reason fiwikisource doesn't have this issue.

I sort of doubt T312042 is a dupe of this. A megadott hitelesítési token lejárt vagy érvénytelen. is centralauth-error-badtoken from the CentralAuth extension. In English that's The provided authentication token is either expired or invalid.

In T312042#8099494, @Aklapper wrote:

See https://www.mediawiki.org/wiki/Manual:How_to_debug/Login_problems in theory. Also, browser info and browser version info are always welcome.