Jump to content

Wikipedia:Interface administrators' noticeboard

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Xaosflux (talk | contribs) at 00:12, 29 April 2021 (→Inactive interface administrators 2021-04-28: d). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

    Welcome to the interface administrators' noticeboard
    Shortcuts

    This is the interface administrator noticeboard, for discussion of interface administrators and coordination of edits to the interface.

    Currently only interface administrators can undelete JS/CSS pages, if you have an uncontroversial undelete or deleted version retrieval request, please list it below.

    Any administrator can delete JS/CSS/JSON pages, for speedy deletions just use a CSD template on the page or its talk page.

    Individual requests for edits to interface or user JavaScript/CSS pages should continue to be made on their respective talk pages.

    Click here to start a new discussion

    0 interface-protected edit requests
    v·h
    Page Tagged since Protection level Last protection log entry
    Updated as needed. Last updated: 04:48, 21 November 2024 (UTC)


    WikEd patch for non-breaking spaces (2)

    Hi,

    Four months ago, I made a request here to add an option to User:Cacycle/wikEd.js.

    It was initially rejected because Cacycle replied that they would have a look. However, I got not reply for two months (see the full discussion User talk:Cacycle#Edit request). Could you please reconsider it?

    Note that last week, I told Cacycle that I intended to re-open this request and I asked if they had any objection, and they did not respond.

    Summary of the original request: I would like this change to be applied to User:Cacycle/wikEd.js. It does not affect the behavior of the script on enwiki, but would allow me to remove the fork on frwiki.

    Orlodrim (talk) 17:04, 12 January 2021 (UTC)[reply]

    @Orlodrim: Cacycle is not inactive and can certainly manage their own personal user script if they want to (Cacycle, if you are fine with others editing your personal script let us know maybe?) - and as you already said you are free to fork, especially if you are on another project - making frwiki editors dependent on a single editor on enwiki is fragile. — xaosflux Talk 17:37, 12 January 2021 (UTC)[reply]
    Editor user_talk notification of this discussion left. — xaosflux Talk 17:39, 12 January 2021 (UTC)[reply]
    Cacycle may simply have no time or no interest in maintaining that script despite being occasionally active. I am not in a hurry, but I hope you will accept to take this request into consideration if they keep not answering.
    I have support on frwiki to remove the fork. I believe that critical bugs on the original version will continue to be detected and fixed faster than what we can do on frwiki, because this user script is also proposed as a gadget on this wiki where it has a much larger userbase (40000 users here vs. 3000 on frwiki), and there are too few people to take care of javascript bugs on frwiki.
    Orlodrim (talk) 18:37, 12 January 2021 (UTC)[reply]
    As the source of one of our gadgets, I wouldn't call it a personal user script. (As such it should really be in the MediaWiki namespace.) Interface admins should be acting on edit requests for gadgets. — JJMC89 (T·C) 05:28, 14 January 2021 (UTC)[reply]
    In 2 10 weeks, Cacycle did not react to my request or to your notification. Would it be possible to apply the change?
    I adjusted the diff link to take into account another fix done by someone else in the meanwhile.
    Orlodrim (talk) 17:44, 26 January 2021 (UTC) 11:29, 27 March 2021 (UTC)[reply]
    Is nobody willing to do this unless Cacycle says "yes", or is it just that my change seems useless for the English Wikipedia so nobody is interested in applying it, or is it something else?
    Orlodrim (talk) 10:42, 27 March 2021 (UTC)[reply]
    Okay, squeaky wheel, give me a minute to find the oil. Izno (talk) 15:09, 27 March 2021 (UTC)[reply]
     Done Izno (talk) 15:12, 27 March 2021 (UTC)[reply]
    Thanks a lot! It works. Orlodrim (talk) 09:53, 11 April 2021 (UTC)[reply]

    Requesting update of User:RedWarn/.js

    The holder of the RedWarn account, Ed6767, is currently unavailable due to personal circumstances. Since the RedWarn team can't access the RedWarn account (per WP:ROLE), I'd like to request User:RedWarn/.js to be updated with the content from https://redwarn.gitlab.io/redwarn-web/redwarn.js, which is the output of the latest pipeline build on the RedWarn repository on GitLab. Thank you! Chlod (say hi!) 17:34, 26 March 2021 (UTC)[reply]

    Confirming. ✨ Ed talk! ✨ 17:35, 26 March 2021 (UTC)[reply]
    {{doing}} reviewing. — xaosflux Talk 20:10, 26 March 2021 (UTC)[reply]
    this is a lot of difference to unpack, will have to get back to this when I have more time (or someone else could pick this up). — xaosflux Talk 20:12, 26 March 2021 (UTC)[reply]
    Apologies for the giant chunk of changed text - it's mostly due to how the build script compresses the CSS in order to decrease file size. The changes made are documented on GitLab, which can be accessed here. The changes consist of the following commits:
    • 2bece7ef by Sportzpikachu (GitLab) - "user highlight on WT:RW"
    • e78ae1dd by Sportzpikachu (GitLab) - "possible fix to #69"
    • e27390ae by Sportzpikachu (GitLab) - "xhr logging for debugMenu using idb" (This has no implications on the production version of RedWarn.)
    • e1f33707 by Sportzpikachu (GitLab) - "fix debug error" (This also has no implications on the production version of RedWarn.)
    • 13be6005 by Sportzpikachu (GitLab) - "temporarily nowiki fix, i srsly am too busy so have some s" (This was a fix to the recent request made to this noticeboard.)
    Please ignore any changes to release/redwarn-web.js, as this is just a development artifact that no one has got around to removing yet. Thanks! Chlod (say hi!) 20:21, 26 March 2021 (UTC)[reply]
     Done — xaosflux Talk 00:36, 29 March 2021 (UTC)[reply]
    @Xaosflux: Sorry to bother you more, but 13be6005 accidentally introduced a crashing bug in the code, I have pushed commit 69402f5a6f34ada28c6f73c69c3ba9a83cde2e7a that should fix it. The build artifact is here: https://redwarn.gitlab.io/redwarn-web/redwarn.js Thanks for your help! ―sportzpikachu my talkcontribs 02:46, 29 March 2021 (UTC)[reply]
    eraser Undone @Sportzpikachu: this has been reverted. Please follow up at User talk:Ed6767 for more updates to this personal user script. — xaosflux Talk 10:04, 29 March 2021 (UTC)[reply]

    CSS page creation request

    Please create a CSS page consisting of: 

    h2, #output, .mw-htmlform-ooui-wrapper, .firstHeading  {
  display:none;
}

    This is to be used for showing just the results of Special:ExpandTemplates. See WP:Village pump (technical)#Linking to template result for the discussion. My specific application is a tool to help DYK nominators and reviewers, but I can envision that the ability to provide a link for displaying the results of a template call could prove to be very useful in many situations. The title of the page doesn't matter to me; whatever the standard convention would be. MANdARAX • XAЯAbИAM 18:48, 28 March 2021 (UTC)[reply]

    I guess this is a request for a gadget, since it is not possible to add arbitrary CSS other than to Common.css or relevant pages. The use is sufficiently niche that doing so there does not make sense to me. Izno (talk) 18:55, 28 March 2021 (UTC)[reply]
    This. @Mandarax: what would you do with such a page? Say we created it at User:Mandarax/Mandarax's_special_css_page.css for example (which you can do right now), then what? — xaosflux Talk 19:05, 28 March 2021 (UTC)[reply]
    @Xaosflux: It's meant for use with withCSS= URLs, to remove the clutter from pages like https://en.wikipedia.org/wiki/Special:ExpandTemplates?wpInput=%7B%7BConvert%7C2%7Cmi%7D%7D. Suffusion of Yellow (talk) 19:32, 28 March 2021 (UTC)[reply]
     Done OK MediaWiki:HidefirstHeading.css is created: @Mandarax and Suffusion of Yellow: — xaosflux Talk 20:06, 28 March 2021 (UTC)[reply]
    Thank you very much! (And I imagine there'll be many uses for this beyond my immediate intentions.) MANdARAX • XAЯAbИAM 21:34, 28 March 2021 (UTC)[reply]
    Could you please add ", #mw-indicator-mw-helplink" to clean it up by removing a question mark and Help link? The code should be:
    h2, #output, .mw-htmlform-ooui-wrapper, .firstHeading, #mw-indicator-mw-helplink {
  display:none;
}
    Sorry I neglected this issue in my first request. My immediate application is a tool for DYK nominators and reviewers. Without this addition, the result will be displayed with an irrelevant Help link for ExpandTemplates, which may confuse users who could think it's for DYK help. MANdARAX • XAЯAbИAM 18:20, 30 March 2021 (UTC)[reply]
     Done @Mandarax: If anyone else wants this modified, or to discuss it further, please open a standard edit request or discussion on the associated talk page. — xaosflux Talk 20:13, 30 March 2021 (UTC)[reply]
    Thanks again! MANdARAX • XAЯAbИAM 20:22, 30 March 2021 (UTC)[reply]
    Could someone please put an example of how this is used at MediaWiki talk:HidefirstHeading.css which would serve as documentation and a reminder for the future. Johnuniq (talk) 20:56, 30 March 2021 (UTC)[reply]
     Done. MANdARAX • XAЯAbИAM 06:30, 31 March 2021 (UTC)[reply]


    Requested CSS page to hide search data

    I request a MediaWiki CSS page, e.g. MediaWiki:Hidesearchdata.css, with this: 

    /* styling for use with custom ?withCSS links */
.searchresult, .mw-search-result-data {
  display:none;
}

    The request is similar to #CSS page creation request. The purpose is being able to make a withCSS link which only shows the page names on a search results page. For example, Category:Pages with disallowed DISPLAYTITLE modifications says: "This search only displays articles in the category". withCSS=MediaWiki:Hidesearchdata.css could be added to the url. searchresult is the excerpt from the page. mw-search-result-data is the size and date. PrimeHunter (talk) 11:49, 29 March 2021 (UTC)[reply]

     Done @PrimeHunter: MediaWiki:Hidesearchdata.css created. — xaosflux Talk 13:03, 29 March 2021 (UTC)[reply]
    Thanks! I have used it in Category:Pages with disallowed DISPLAYTITLE modifications and it works. PrimeHunter (talk) 13:12, 29 March 2021 (UTC)[reply]
    If we're going to add too many more of these ad hoc MediaWiki CSS pages (which I do not think is a good idea btw), consider a template to keep track of them and/or link to them and/or link between them. --Izno (talk) 15:08, 29 March 2021 (UTC)[reply]
    @Izno: Category:Wikipedia ad-hoc CSS pages maybe? — xaosflux Talk 15:17, 29 March 2021 (UTC)[reply]
    I was actually planning to make a list for both withCSS and withJS, explaining how they work and give links and descriptions to those which are known. Pppery mentioned three JS at Wikipedia:Village pump (technical)#Linking to template result: MediaWiki:ExcerptTree.js, MediaWiki:G13-restore-wizard.js,MediaWiki:FileUploadWizard.js. The feature is described at mw:Snippets/Load JS and CSS by URL. The code is in MediaWiki:Common.js. PrimeHunter (talk) 16:23, 29 March 2021 (UTC)[reply]
    FYI Wikipedia:Dispute resolution noticeboard/request uses ?with= resources. — xaosflux Talk 18:07, 29 March 2021 (UTC)[reply]
    @PrimeHunter the output is ugly. if there's going to be whole MW css page for this, we can aim for better presentation. Maybe remove all the extraneous spacing and add bullets before page names? Adding something like this prettifies things to an extent:
    .mw-search-result-heading a::before {
    content: "\u2022 "; /* bullet */
}
.mw-search-results li {
    padding-bottom: 0;
}
    – SD0001 (talk) 11:08, 30 March 2021 (UTC)[reply]
    @SD0001: It wasn't ugly for me but that's apparently only because I have enabled "PrettyLog" at Special:Preferences#mw-prefsection-gadgets. Your CSS gives me the string "u2022" displayed before the page name. PrimeHunter (talk) 12:16, 30 March 2021 (UTC)[reply]
    There should be no u in the code, i.e. content: "\2022 ";. However, it’s still hackish, it’s much easier and nicer to just enable the native bullet points: 
    .mw-search-results li {
	padding-bottom: 0;
	list-style: unset;
}
    —Tacsipacsi (talk) 17:36, 30 March 2021 (UTC)[reply]

    A pair of banner hiding gadgets

    Do we still need:

    • Suppress display of fundraiser banners
    • Suppress display of CentralNotices

    in gadgets? We have a spiffy new banners tab in preferences these days. Izno (talk) 23:48, 1 April 2021 (UTC)[reply]

    @Izno: well, suppose the fundraiser one could be migrated - but people would need to go opt-out of the notice since it is on by default. As far as the other one, the preferences doesn't let you turn off "important" types of notices (or I'm assuming malformed notices that don't declare one of these types) so the second could still be useful. — xaosflux Talk 08:47, 10 April 2021 (UTC)[reply]
    The fundraising gadget can definitely be deprecated. I don't think the fundraising team have run fundraising banners to logged in users in nearly a decade and the new preferences handle not just WMF fundraising but also tax campaigns by affiliates. The new preference needs two more categories added and once that is done I would encourage people to migrate to using preferences and we deprecate . There are clear advantages to the preferences option and one of the reasons it got built was to allow people to be more selective on what banners they could ignore, it also exists everywhere. Broadly speaking the only real exceptions that cant be opted out of are maintenance banners, and rare instances involving all logged-in users such as a significant terms of use change. Seddon talk 10:34, 20 April 2021 (UTC)[reply]
    @Seddon: also, of all the banners the fundraising ones if used are most likely to properly declare their type. As far as deprecation goes though, the preference requires an "opt-out" action, so at the least we'll want to somehow let our users know, we have 28,314 users using it now - see next section for some ideas. — xaosflux Talk 11:46, 20 April 2021 (UTC)[reply]

    Deprecating a script/gadget

    So I've been thinking about this for a little while, and wanted some ideas on a standard. We have multiple instances where we want to turn down a user script or gadget that is in use because a replacement is available (like the example above of a gadget->preferences migration; but also when we have a userscript->gadget migration). These require an opt-in preferences action from our users. Would like to have some repeatable, standard-ish way to notify them - perhaps a banner/popup/etc that can be put on their "old" script during a transition period. Open for ideas and samples here if anyone has already done some of this? — xaosflux Talk 11:46, 20 April 2021 (UTC)[reply]

    Can’t gadgets turn on the new preference and then turn off themselves? Preferences (including enabled gadgets) can be modified through the API, to which gadgets have access. Of course this doesn’t work for user script→gadget migration and can happen only when the gadget actually loads, so inactive users will still have the gadget enabled, but it would provide a seamless gadget→preference (or gadget→other gadget) transition for somewhat active users. —Tacsipacsi (talk) 12:06, 20 April 2021 (UTC)[reply]
    Gadgets do not run on Special:Prefs for security purposes. Gadgets with configuration store them in local JSON or similar. Izno (talk) 14:17, 20 April 2021 (UTC)[reply]
    That’s true, but my proposal was to use the MediaWiki action API, which would mean (if it works) that the user wouldn’t even have to visit their preferences, the transition script would run on any other (non-restricted) page. —Tacsipacsi (talk) 17:39, 20 April 2021 (UTC)[reply]
    @Tacsipacsi: do you have any proof of concept code for this? As you are an int-admin on huwiki I can add you as one on testwiki if you want to try there (ping me at testwiki:user talk:xaosflux). — xaosflux Talk 19:12, 20 April 2021 (UTC)[reply]
    Take a look at User:AzaToth/twinkle.js; it takes the former (ancient!) home of a userscript and enables the gadget if not enabled. ~ Amory (u • t • c) 19:39, 20 April 2021 (UTC)[reply]
    @Amorymeltzer: thanks so that is good for userscript-->gadget (and once that has time to bake in we can remove the known imports); got one for script/gadget --> preference? — xaosflux Talk 23:09, 20 April 2021 (UTC)[reply]
    Same thing: gadgets are a "preference" with a specific naming structure. Any other preference can be done the same way, presuming the value is valid. So, for example, something like new mw.Api().saveOption('skin', 'modern'); would change your skin preference (for the better). ~ Amory (u • t • c) 23:53, 20 April 2021 (UTC)[reply]
    Exciting. I can think of some scripts currently imported that really should move users to the gadget version. Izno (talk) 03:30, 21 April 2021 (UTC)[reply]
    Indeed this trick is quite underused in practise. I suggested it for twinkle and also for Prosesize when it became a gadget. It's a good way to migrate users without annoying them with pop-ups or banners, but not good to keep around long-term (makes it difficult for users to disable the gadget when they want to – the script would enable it back!) Ideally I would say put it in place for 6 months then remove – anyone who logged in to their account in those 6 months would be migrated. – SD0001 (talk) 07:57, 21 April 2021 (UTC)[reply]
    • Hmmm, so looking at HideFundraisingNotice[ResourceLoader]|HideFundraisingNotice.css looks like to pull this off we would need to add an additional .js file to this gadget, but then that could set the preference ("centralnotice-display-campaign-type-fundraising": 0,), then potentially turn itself off ("gadget-HideFundraisingNotice": "0",) right? — xaosflux Talk 23:31, 22 April 2021 (UTC)[reply]
      @Xaosflux: Yes. Can be done with a single API call: new mw.Api().saveOptions({ "centralnotice-display-campaign-type-fundraising": 0, "gadget-HideFundraisingNotice": "0" }) (used saveOptions instead of saveOption). – SD0001 (talk) 13:18, 26 April 2021 (UTC)[reply]
    OK, will test out on testwiki then I think the fundraising supress gadget-->preferences is a easy product case; any objections? — xaosflux Talk 13:43, 26 April 2021 (UTC)[reply]
    I'm on board with this. Let me know if I can assist at all. Seddon talk 00:21, 27 April 2021 (UTC)[reply]

    About deploying StructuredCategories in English Wikipedia

    Dear all,

    I have recently developed a new tool that returns a structured description of a given Wikipedia Category based on the Wikidata Statements involving its direct members. This tool is called StructuredCategories and is described at d:Wikidata:Structured Categories. I ask this tool can be deployed in English Wikipedia and added to Preferences as a Gadget. The source code of this JavaScript tool is available at meta:MediaWiki:Gadget-StructuredCategories.js.

    From a technical point of view, the deployment of StructedCategories includes:

    • Pasting this code mw.loader.load('//meta.wikimedia.org/w/index.php?title=MediaWiki:Gadget-StructuredCategories.js&action=raw&ctype=text/javascript'); in MediaWiki:Gadget-StructuredCategories.js.
    • Writing a translation of StructuredCategories: provide a structured description of a category based on Wikidata statements involving its direct members in MediaWiki:Gadget-StructuredCategories.
    • Adding the tool as a Gadget.

    I ask if this is possible. — Csisc (talk) 21:49, 20 April 2021 (UTC)[reply]

    @Csisc: hi again! This could certainly be possibly, however we are usually a bit picky about adding new gadgets. I suggest you first offer it as a tool that users can test in their userscripts, and you may advertise that at WP:VPM. For the page that needs to be translated first, you can ask for a volunteer on that page as well. Once ready and tested, you can propose we add it as an opt-in gadget by starting a discussion at Wikipedia:Village_pump_(technical), if it shows a consensus to add one of our interface-admins will activate it. — xaosflux Talk 22:52, 20 April 2021 (UTC)[reply]
    xaosflux: Excellent idea. I already started a discussion at Wikipedia:Village pump (technical)#About deploying StructuredCategories in the English Wikipedia. However, advertising the tool at WP:VPM is an excellent idea. I will apply it. --Csisc (talk) 01:09, 21 April 2021 (UTC)[reply]

    Preview warnings and hatnote TemplateStyles

    Pages watchers may be interested in MediaWiki talk:Common.css § Preview warning and hatnotes moving to TemplateStyles. Izno (talk) 01:08, 23 April 2021 (UTC)[reply]

    Inactive interface administrators 2021-04-28

    The following interface administrator(s) are inactive:

    — JJMC89 bot 23:19, 28 April 2021 (UTC)[reply]

    Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Interface_administrators%27_noticeboard&oldid=1020420889"