The current configuration to get Linter working on a MediaWiki instance is... curious, to say the least. Merging it into core should solve that too.

Well, gadgets are not limited to Wikimedia sites. In this sense they are pieces of software more associated with MediaWiki than Wikimedia, similar to extensions and skins (which are documented in mediawiki.org and already have their own namespaces).

Done, check it out and let me know if you notice any issues!

I just sent a new patch for review that implements this feature. I basically copied the old patch with a few minor changes. The config variable is now named $wgPopupsNamespaces instead of $wgPopupsNamespacesEnabled for simplicity and consistence with other similar variables, like $wgContentNamespaces, $wgPageImagesNamespaces, etc.

Perhaps the CSS can be reverted by a user-style or user-script for those that don't like it or need it for some specific workflow reason?

Hi! I just re-run the global code search and it seems like several wikis already removed their legacy gadgets.

Hi! I just submitted a new patchset for this feature, at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1114712

Yet another way would be enhancing Extension:MediaViewer to support opening SVGs generated via Lua. Perhaps a CSS class that when found, will trigger MediaViewer?

Another solution would be some way to get the data-URL of the SVG. We could then use that URL to offer a link to the full-size version of the map below the thumbnail. T407710 seems related.

One simple solution would be offering a link that opens the full-size map in a new tab. This is actually possible by right-clicking the map and then clicking "Open image in new tab". However, most users won't find this. Perhaps if there was some way to wrap the generated <img> with <a> so that when the user clicks it, it opens in the full-size map in a new tab? Something like svg:toLinkedImage() instead of svg:toImage()?

@Anjali_ojha68 Hi! I'm the main developer of the Proveit gadget, thanks so much for wanting to contribute! I see you already uploaded a patch set. Unfortunately, the code on Gerrit (mediawiki/gadgets/ProveIt) was completely out-of-date, because a couple months ago I finished a major rewrite of the code and I didn't push it to Gerrit (sorry). FYI, the actual live code served on Wikipedia is always here, and I try to keep Gerrit synced, but this time I didn't. However, I just did. Would you like to try updating your patch to the new code? Let me know, cheers!

We would need community approval, as the tag should be added to each Wikipedia's Special:Tags.

See here for an example of the kind of charts produced via mw.track

I'd like to add my support for a $wgPopupsNamespaces config variable. I don't see why popups should be limited to content namespaces. In our use case (appropedia.org) we want popups on user pages, help pages, project pages and even category pages. Adding all those namespaces to $wgContentNamespaces just to enable popups there is begging for trouble. As a workaround, we've added said namespaces to $wgContentNamespaces but only via JavaScript (from MediaWiki:Common.js) and it works, but it's still a workaround/hack and is likely to cause some issues down the road. If no one objects to it, I may try sending a patch myself in the near future.

That was it, thanks!

I recently uploaded a new extension to Gerrit (here) and expected "wikimedia/client" to require ES8, but apparently it still requires ES7? Do extensions still require ES7, or am I missing something?

Closing until further explained.

This is mostly implemented, but the "extends" feature of the Extension:Cite hasn't been deployed yet.

After some thought, I can't think of a much better way to handle numbered parameters than we currently have (currently, we can filter parameters by name or number). Once T54582 is implemented, Proveit will need to be improved to recognize the new template data patterns for numbered parameters. But that's another task.

While T54582 is relevant, it isn't strictly needed to approach this task, as Proveit could recognize auto-numbered parameters with a simple regex.

See https://www.mediawiki.org/w/index.php?title=MediaWiki:Gadget-Global-ProveIt.js&diff=prev&oldid=7862660

Should be fixed now. :-)

All reported issues should be fixed now. Let me know otherwise!

Issue 4 should be fixed now (diff). I'll look into the rest tomorrow.

I recently changed max-width: 700px; for width: 700px; in the CSS of #proveit-body. Is the issue still happening to you? If yes, what browser are you using? Thanks!

That was an intermediate "fix" where I screwed up. The good fix is already deployed, but the old one must still be in your cache. Please hard-refresh or wait a few minutes to confirm it's fixed now. Cheers!

The issue with the labels not showing should be fixed now.

Done! Now, when the content of a reference (or even a list item!) matches one of a few "citation patterns", Proveit can convert it to a citation template by clicking the "Detect template" button. Can be tested in the development version (see my common.js) and will be deployed in a few days.

Ah screw it, I just added tooltips to every single button. Let me know if you'd change any. Cheers!

Ah, yes! I agree, ordinary "title" attributes won't be annoying. I just added the following:

@voorts Hi, thanks for the report! Currently, Proveit shows the content of the required fields of each template. Template:Sfnm didn't have any fields marked as required in its template data (in fact it didn't have any template data at all) so the full wikitext was shown instead. I just added some template data for it (diff) so the snippets should look much better now. Feel free to extend and refine the template data if you want. Unfortunately, template data is not really designed for handling arbitrary numbers of parameters like Template:Sfnm has (see T54582) so Proveit can't handle them very well either, but I think the snippets are at least decent now.

@Iniquity I just added your (second) suggestion to the proveit config so that we can exclude arbitrary templates from the "Add reference" form, without having to hard-code their names. Thanks!

Hi! The templates {{Sfn}}, {{Sfnm}} and {{R}} are meant to be inserted via the "Add bibliography" button (now renamed to "Add template", see T403334#11134235).

Hi! Regarding "Add reference" and "Add bibliography", the first inserts a <ref> tag (usually with a citation template like {{Cite book}} inside, but not necessarily), while the second inserts a plain template (that is, a citation template like {{Cite book}} or {{Sfn}}, but without the surrounding <ref> tag).

I just added Template:Sfn and Template:Sfnm to the list of supported templates (diff).

I just tried generating a reference from that same archive URL (https://web.archive.org/web/20090903091215/http://www.fpif.org/fpiftxt/4951) and everything went smoothly:

Hi! I looked into this and did a few tests, but I found the prototype syntax really ugly and confusing, so I ended up switching to the more modern classes which rely on prototypes internally (so the methods are no longer attached to every object) but have a much more palatable syntax (at least to my taste). Can be tested in the development version (see my common.js) and will be deployed in a few days.

Not sure I understand you. Are you suggesting using <cdx-popover> as the main component of the gadget? If so, I think it's a good idea, but would require a major rewrite. Would it give us a some concrete advantage worth the effort? Do you think it would somehow help solve the tooltip issue?

I have improved the UI and changed the success message to "Please test the archived URL before using it".

This is hardly necessary because references to convert aren't all that common and when they do happen, they can be easily converted by opening up the reference, copying the URL to the Citoid or "Automatic reference" field and hitting the "Load" button.

Proveit now generates and normalizes dates using Intl.DateTimeFormat and using the following format by default:

{ year: 'numeric', month: 'long', day: 'numeric' }

This format seems appropriate for the English, French and Spanish Wikipedias, and probably many other wikis. However, when not appropriate, it can now be configured via the Proveit initialization code by setting, for example:

mw.config.set( 'proveit-date-format', { year: 'numeric', month: 'numeric', day: 'numeric' } );

The new behavior can be tested in the development version (see my common.js) and will be deployed in a few days. I will document the new config option at https://www.mediawiki.org/wiki/ProveIt after deployment.

Ok I think I get what you mean now. I added a "Normalize" button that appears on date fields but ONLY when their content has the format of a Wayback Machine timestamp (which by the way is the same format of MediaWiki timestamps). When the button is clicked, it will convert the timestamp to the preferred YYYY-MM-DD format. The new button can be tested in the development version (see my common.js) and will be deployed in a few days.

If you paste your URL in the "Automatic reference" field and hit the "Load" button, Proveit generates the reference and correctly sets the archive date to the YYYY-MM-DD format. Is this what you wanted?

Done, see diff.

Done! Can be tested in the development version (see my common.js) and will be deployed in a few days.

Unfortunately, it seems the Codex tooltip directive made the Proveit form painfully slow, so I had to revert to the previous CSS-only solution.

Position is now persistent across sessions. Can be tested in the development version (see my common.js) and will be deployed in a few days.

@Iniquity I just modified the development version as mentioned: English messages are hard-coded and the translations are fetched from Gerrit. When that fails (because of the 403 error, or because the requested language is not available, or whatever), the English messages are shown, and on English wikis, we save one request. I also prefer this solution now. Thanks for helping me see clearly and decide!

Support for RTL has now improved significantly due to the adoption of Codex. Can be tested in the development version (see my common.js) and will be deployed in a few days. The interface in Arabic looks decent to me and since no one has really complained about RTL support, I'm closing this as resolved until someone brings up any actual bugs or issues.

Stalled until further explained.

Fixed by switching to Codex tooltips. Can be tested in the development version (see my common.js) and will be deployed in a few days.

Done! Can be tested in the development version (see my common.js) and will be deployed in a few days.

@Iniquity Hi! They don't. Setting up a Gerrit repo for Proveit, connecting it to TranslateWiki, and loading the translations from there was an experiment. These 403 Forbidden errors me and other users are now getting from Gerrit point to the limitations of this experiment, so I thought it was time to regress to a "safer" alternative, that is, hosting the translations at Commons, where they can be translated by Wikimedia users (but not by TranslateWiki, granted).

Done! Translations are now hosted at https://commons.wikimedia.org/wiki/Data:Gadget-ProveIt.tab and fetched from there. Can be tested in the development version (see my common.js) and will be deployed in a few days.

The benefit is not worth the effort and no one has really complained about the current situation.

Done! Can be tested in the development version (see my common.js) and will be deployed in a few days.

Done! Can be tested in the development version (see my common.js) and will be deployed in a few days. The "Previous" and "Next" buttons are in the header rather than the footer (for consistency to the way I think and designed the UI) and may undergo minor changes before deployment, but are essentially done.

Done! Can be tested in the development version (see my common.js) and will be deployed in a few days.

@Dylsss The original version of the module actually aimed for that, but not being able to output input fields, I had to resort to divs that were then made editable via JS, and other hacks (imagine radio buttons), which ended being a complicated and ugly monster. When I switched to JS-based, the code and final output improved enormously.

Hi! I'm trying to use Codex icons in a user script but can't get it working. I can query the API ok, but how do I integrate the data I get with the CdxIcon component? Can we have a code example somewhere? Thanks!

Hi again! Since some users appreciated the "style" parameter (see T401659) I'd like to re-add it using the CSS sanitation proposed earlier:

if ( style.toLowerCase().indexOf( 'url' ) > -1 ) {
	style = '';
}

Any objections? Thanks!

Proveit now features an Archive button next to URL fields, that fetches for the latest archive.org snapshot and shows the URL to the user. The user may then copy the URL and paste it in the relevant archive field. Pasting it automatically to the relevant archive field is not straightforward because the name of the field varies per-wiki and per-template, so doing so would require per-wiki and per-template configuration, which seems overkill.

Gadgets 2.0 seems abandoned.

The underlying cause of this issue was fixed in core, so I removed the workaround code in ProveIt.

All done. If someone wants to review this, we can close it. Cheers!

Thanks, that was it. I was testing in REL1_43.

Hi! Well, I sent the diff for review but now Jenkins is complaining about not finding #wpTextbox1 or something. I tried to fix it but failed. I would appreciate any help or guidance on this annoyance. If not, I'll remove Jenkins vote and merge anyway. Cheers!

Hi! I'm happy to hear that fetching localization messages from Gitiles is a valid use case, but I think I will replace it for a more standard approach that fetches the messages from a wiki page at mediawiki.org or something (experience has taught me that the most reliable environment are always the wikis). I'm currently requesting a grant to update and improve the gadget anyway, so I'll add this to my to-do list.

Not sure how to proceed with these kind of security fixes. Should I adapt and apply that diff to all the branches and merge them directly via "git push" rather than "git review"?

@Peachey88 Ah yes, that's probably the cause, I'm running Chrome v103.0.5060.132 (64-bit) and I've been unable to update for some time because apparently my laptop is too old.