In T312587#9221655, @DLynch wrote:

QA testing note: because of the throttling of notices, you'll either need to find a new page with a notice to test each time you look at it, or you'll need to run localStorage.clear() in your browser console before loading the editor.

In T312587#9209218, @Quiddity wrote:

@ppelberg I think we might need to rework that a bit. Ideally a Tech News item would primarily link to a translatable documentation page (not to Enwiki)

I just created https://meta.wikimedia.org/wiki/EditNoticesOnMobile which could be made translatable I think.

In T304073#9161657, @Umherirrender wrote:

See also T270057 for a way to get the current expiry in the browser

In T346115#9164332, @Nux wrote:

Did you ever thought of using NodeJS?

You could keep some of your code, but do it in an automated manner. You can loop over many pages to gather data and save locally (as files or in DB).
Then deploy this to Wikipedia in a simple script.

I've recently discovered this JS module for doing API request to MediaWiki: MWN JS library.

Saving things back to Wikipedia can be done either directly with MWN or if you generate file then you can use WikiployLite which kind of makes thing easier (you only provide configuration for that). When you use either of those methods you can use a local Jenkins installation that just runs your scripts on certain time.

You can find an example of how to use MWN here:
https://github.com/Eccenux/wiki-wd-mass-modyfication/blob/b1f8e19c89c17eed1a68bbea255a2d5b41378b96/runBot.js

You'll find that WikiBotLite is even a thinner layer over MWN then WikiployLite is:
https://github.com/Eccenux/wiki-wd-mass-modyfication/blob/b1f8e19c89c17eed1a68bbea255a2d5b41378b96/src/WikiBotLite.js

This was the original task description before Aklapper replaced it with the log :

In T344999#9169383, @Aklapper wrote:

Thus I will be helpful once more and reopen this task to allow for more input.

I'd still decline this as input seems to have been provided...

In T344822#9147204, @SBisson wrote:

In T344822#9147119, @AlexisJazz wrote:

I reported this over a year ago, but um sure I guess.

If you do fix it the Wikistories will actually break completely due to T344605.

Thanks for letting us know. We'll wait for a fix there before switching our config to the beta Commons.

You might find running https://en.wikipedia.org/wiki/User:Alexis_Jazz/EverybodyLikesPie.js to be of some help on these projects. See https://it.wikisource.org/w/index.php?title=Utente:Alexis_Jazz/Sandbox&oldid=3227820 for example.

@Nux Thanks, it works now. :-)

I suppose an alternative option would be some additional "extend-expiry-but-don't-overwrite-indefinite-watching" parameter added to everything, but I imagine that'd be far more confusing.

That would be T304073.

I made a proof of concept: https://en.wikipedia.org/wiki/User:Alexis_Jazz/EverybodyLikesPie.js

In T345960#9159886, @Aklapper wrote:

@AlexisJazz: Please stay on-topic. Random past board or ban stuff has nothing to do with guiding site admins about technical issues. This is not a forum. Thanks!

In T345960#9158596, @Jdlrobson wrote:

The key bit of information in this task description is We should be doing more to guide site admins on when they are introducing performance/SEO problems to the site. (key word "guide" not prevent :-))

For a single library that is loaded by many users as it's required for VE I think those are some nice savings on both traffic and localStorage. Thank you. :-)

In T345960#9154974, @Izno wrote:

In T345960#9154958, @AlexisJazz wrote:

The developers are in for a world of hurt if CommRel doesn't get involved in this.

I think you're mischaracterizing this task. It's only to know and provide info on, not to do anything listed in "Future uses". Some of the items in that list likely have some communications desirability and working through with communities, but being able to provide numbers to users seems like a reasonable thing to do without any particularly adverse impact.

In T345960#9154923, @Aklapper wrote:

This task does not look like a task requesting support from CommRel-Specialists-Support

If it's possible to check this quickly on edit

I can't reproduce this anymore on betacommons so seems good to me. :-)

In T111565#9141090, @Msz2001 wrote:

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).

Ah, appears that you're right. I must have missed the on-wiki code that supports it.

I reported this over a year ago, but um sure I guess.

In T340705#9006917, @Jdlrobson wrote:

In T340705#8986782, @stjn wrote:

I have added targets=desktop to some gadgets because I was receiving reports from users and seeing some errors in consoles after this change, and now I have to ask: what to do, for example, about https://ru.wikipedia.org/wiki/MediaWiki:Gadget-collapserefs.js if targets=desktop goes away? Like, I would be perfectly fine with throwing it away entirely, but since I don’t have that power, outside of that: it is a gadget that allows some users to collapse references by default. It doesn’t make sense to have it in mobile Minerva since it collapses all sections, but people can use desktop Minerva and expect this gadget to be there. Unless we’re giving up on the plan to remove targets=desktop, of course, then disregard my comment.

@stjn in the case of https://ru.wikipedia.org/wiki/MediaWiki:Gadget-collapserefs.js I would suggest limiting it to Minerva skin. Very few people use desktop Minerva and I doubt those that do would care for this gadget.

In T343131#9140322, @Ladsgroup wrote:

One new and easy low-hanging fruit:

Remove template styles for Template:Information and cc-by-sa license: https://commons.wikimedia.org/wiki/Module:Information/styles.css and https://commons.wikimedia.org/wiki/Template:Cc-by-sa-layout/styles.css
Move them to common.css instead.
Why?

Yeah, why not https://commons.wikimedia.org/wiki/MediaWiki:Filepage.css ?

For individual cases/articles, navboxes (and other templates that mobile users are normally excluded from) can be forced using https://en.wikipedia.org/wiki/Template:Strip_nomobile.

In T111565#9137021, @matmarex wrote:

As there are people opposed to making this change in MediaWiki core, I would suggest doing it in your wiki's MediaWiki:Common.js or a gadget, as long as your community finds that agreeable.

@Tossrock while this seems already solved, for future reference you can use !important to override style-defined attributes. For example:

.sidebar-collapse{background:blue !important}'

In T111565#9135498, @Izno wrote:

In T111565#9135467, @AlexisJazz wrote:

I can't find the relevant comment, but this is deemed to be an insufficient UX on touchscreens by the WMF devs.

You're probably looking for the patch commentary in https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/859605/ . It's the only place I've seen an objection along this line in recent times.

TBH I'm in the party of "the perfect is currently being the enemy of the good" regarding allowing things to be collapsed. I get the concern regarding button size, but OTOH I don't see it as major enough to block the enhancement that collapsing things brings.

In T111565#9135136, @Msz2001 wrote:

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());

Tested at: https://m.mediawiki.org/wiki/Manual:Collapsible_elements/Demo/Advanced

In T312587#9130294, @Esanders wrote:

EditNoticesOnMobile and edit notices in VE on desktop provide this button

For ENOM the button is only visible on tablet-width devices, so the vast majority of users don't see this button. I don't think this is a problem.

In T344999#9121843, @RhinosF1 wrote:

I suspect UBN! wouldn't have been appropriate as I think (but I could very well be wrong) that only applies to considerable issues on production.

Anything that blocks the train is unbreak now

In T344999#9121700, @abi_ wrote:

Thank you @AlexisJazz for reporting the issue in question (T344635). I want to apologize for dropping the ball on that ticket.

When I reviewed the ticket, I immediately made the assessment that the issue is severe, triaged it as high priority and submitted a fix for it. I was not sure about marking at as UBN!, and a train blocker, but went ahead and submitted a back-port patch in case someone judged that it was a train blocker. Looking back, I should have marked it a train blocker and back-ported it. Note to self: when in doubt, err on the side of caution, make noise and get multiple inputs.

I do not have a lot to add to the current discussion, the processes that come to my mind are a bit redundant to what we already have. In general, I think It would be nice to have more eyes on high priority bug reports after group0 deployment in order to reduce the impact of error in judgements.

In T344999#9120985, @Aklapper wrote:

so why didn't YOU tag T344635 as a train blocker? As you see, playing the blame game is easy, but it doesn't help anyone.

Either nobody realized that it should have been marked as a train blocker, or nobody considered it a train blocker given human judgement at that point in time.
I tried to explain above how anyone who thinks an issue might be a train blocker could mark it as such regarding current workflows.

Personally, I didn't realize it. I have a lot on my mind, am unpaid (it's unreasonable to hold me to the same standards as the paid workforce) and the workflow is not intuitive.

In T344999#9120647, @Aklapper wrote:

Unlike you, I'm not getting paid so telling me how I should work, especially when it's not particularly intuitive, is unlikely to pay off.

Sure. That's why I pointed out existing workflows, and not using existing workflows definitely won't pay off either... :-/

In T344999#9120614, @Aklapper wrote:

and it clearly didn't help.

We won't fix either a social or a workflow problem by introducing competing workflows. :) Thus declining.

In my understanding, going to Edit Related Tasks... and selecting Edit Parent Tasks is the workflow to mark an issue as a train blocker, after looking up the current train task ID.

In T344999#9120584, @taavi wrote:

How would this be different from Beta-Cluster-reproducible?

In T344680#9111471, @Aklapper wrote:

(For the records, I once created T279421: Update Vue and Codex documentation for WMF staff and community developers about the insufficient documentation and communication at that time.) Its original title was Document and communicate status of Vue things (Codex) and future of OOUI, WVUI, etc.

In T344704#9109942, @Johannnes89 wrote:

Note: Multiple dewiki users were reporting a similar problem regarding the IP 10.80.1.7 which also doesn't belong to those users (same /28-range as 10.80.1.11)
https://de.wikipedia.org/w/index.php?title=Benutzer_Diskussion:XenonX3&oldid=236646961#Nutzersperre

https://en.wikipedia.org/w/api.php?action=query&meta=userinfo&callback=&format=json&formatversion=2 now returns my actual IP. Thanks for the quick response!

I'm no longer blocked as on https://en.wikipedia.org/wiki/Special:Contributions/ST47ProxyBot this message can be read:

Forgot to mention: error happens both when logged in and not logged in.

In T312587#9106636, @DLynch wrote:

I don't think we can expect our users, especially on mobile devices, to open the browser console and enter a command to view the notice again

Oh, sorry, I thought you were just asking for testing purposes on the patchdemo.

This link is unrelated to my question, correct?

I might need some clarification as to what your question was, in that case?

In T312587#9106278, @DLynch wrote:

The patchdemo has no way to view the notice again after dismissing it, is this correct?

@AlexisJazz you could run localStorage.clear() in the console.

@ppelberg https://phabricator.wikimedia.org/rMEXTd046bc1d44faf877e2e71cd7f46b20371ef04e32 : "Won't show an edit notice with the same key on the same page for 1 day after it has been seen." is that it?

https://phabricator.wikimedia.org/rMEXTd046bc1d44faf877e2e71cd7f46b20371ef04e32 : " Edit notices are not shown if the user has the EditNoticesOnMobile gadget enabled."

In T341421#9104612, @Tacsipacsi wrote:

In T341421#9104345, @AlexisJazz wrote:

Maybe related to the changes made in T328610 ?

Yes, I think so.

In T341421#9000004, @AlexisJazz wrote:

You could use targets=desktop instead which has nearly the same effect.

“Nearly the same effect” includes causing this bug since 8af75aa…

Maybe if the gadget is unavailable due to the current skin/target, the option should be disabled rather than hidden? It would show some gadgets that are planned for non-default skins and thus irrelevant for most people, though.

Or don’t show all gadgets unavailable due to the current skin, but do show gadgets that are, while unavailable on the current skin, are available on the skin set in the preferences (which is Vector even when using the mobile domain), and show gadgets regardless of their target settings (the target setting should go away soon anyway).

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.