MediaWiki talk:Gadget-AjaxQuickDelete.js

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 20 days.

TO DO

  • Watching MediaWiki talk:Gadget-AjaxQuickDelete.js/auto-errors
  • Using tokens from mw.user.tokens.get() if this is faster
  • Using mw.message
  • Ability to swap images even on the second screen. Currently, we are unable to swap images if the files are exactly the same.
$.createSpinner({
   size: 'large'
})

move failed for File:Sant Martí de Sadevesa (added ".file:sant martí de sadevesa:" after the intended name)

File:Sant Martí de Sadevesa.jpg (see history). Thanks for investigating and fixing. OT: In case someone is interested, the image is now at: File:Sant Martí de Sadevesa, 2011.jpg Cheers --Saibo (Δ) 01:20, 18 December 2011 (UTC)[reply]

Rare case: "Source file" (actually no file but page) had no extension.
currentExtension = wgPageName.toLowerCase().replace(/.*?\.(\w{3,4})$/, '$1').replace('jpeg', 'jpg');
 
// If new file name is without extension, add the one from the old name
if (uncleanName.toLowerCase().indexOf(currentExtension) == -1) uncleanName += '.' + currentExtension;

-- RE rillke questions? 01:33, 18 December 2011 (UTC)[reply]

REMOVE spam/whatever filter from obstructing copyvio-tagging

When script-tagging an upload as copyvio by adding http://"www.aceshowbiz.com/events/Harry%20Potter%20and%20the%20Deathly%20Hallows:%20Part%20II/jade-gordon-world-premiere-deathly-hallows-part-ii-01.html" into the script window, I got reproducibly the following error message and the process stopped.

  • "Während der Ausführung einer Aufgabe, trat ein Fehler auf. Folgend eine Detailbeschreibung des Fehlers: The edit failed because www.aceshowbiz.com is on the Spam Blacklist"

This is not acceptable, as this unnecessarily increases the amount of work to tag copyvios. The spam-filter should really NOT be applied to tools such as marking a file as copyvio. --Túrelio (talk) 14:52, 30 January 2012 (UTC)[reply]

I fear nothing I can change. It is on meta:Spam blacklist our local is MediaWiki:Spam-blacklist. Spam blacklist is a stupid piece of software... and I am not inclined having a dispute with Tim S. because this will lead to nowhere. -- RE rillke questions? 16:08, 30 January 2012 (UTC)[reply]
bugzilla:34928 -- RE rillke questions? 10:56, 15 March 2012 (UTC)[reply]

Split out tools requiring elevated privileges aka user rights

I suggest to split out

  • The duplicate processing part and make it available for sysops (on by default) in the gadget section "Tools for authorized users"
  • The file moving stuff and make it available for filemovers and sysops (on by default) in the gadget section "Tools for authorized users"

One has to be careful, though, not breaking depending tools like RenameLink or MediaWiki:ProcessFileMoverRequests.js.

This would allow further customisation, stop this strange mixture of tools in one file and reduce the amount of code to be loaded for the average user. -- Rillke(q?) 11:00, 13 September 2012 (UTC)[reply]

disable move&replace

Is there any way to use this script without the move&replace feature? --Krd 09:36, 16 February 2013 (UTC)[reply]

Currently there is no way. You can open the link in a new tab. See #Split out tools requiring elevated privileges aka user rights. BTW, what's the issue with Move&Replace? -- Rillke(q?) 13:29, 16 February 2013 (UTC)[reply]
Ah, the open-link-in-new-tab approach is perfect, thank you! If i'm not mistaken, the m&r is not helpful for example when splitting overwritten files, as the cleanup has to be done manually in most cases, and even when I unchecked the replace checkbox a bot order had been created. --Krd 19:25, 16 February 2013 (UTC)[reply]
Indeed. Perhaps a note at COM:SPLIT would be helpful. Compared with usual file moves, history splitting is rarely done so I am not sure whether it would be wise adding another option. -- Rillke(q?) 09:50, 17 February 2013 (UTC)[reply]
It is ok as it is, no change needed, as the shown workaround works well. Thank you again. --Krd 12:28, 17 February 2013 (UTC)[reply]

Hmm, is "leave a redirect behind" supposed to be de-selectable? It's greyed-out for me, I can only disable the replace via useraccount option. FF 17.0.4 ESR and Monobook. --Denniss (talk) 00:41, 24 March 2013 (UTC)[reply]

If I look at the code, it is supposed to be disabled when the file is in use. -- Rillke(q?) 21:04, 24 March 2013 (UTC)[reply]

Bug report

Please see Commons:Village_pump#Technical_problem_with_AjaxQuickDelete. Mono 00:39, 24 February 2013 (UTC)[reply]

The script notifies, assuming it's the creator, the user of the first revision. In case of an import, it may notify the wrong person. If you have a fix, it would be great; otherwise it will be difficult to implement a check for this in the near future, I guess.-- Rillke(q?) 15:17, 24 February 2013 (UTC)[reply]

Dashes in signature

IMO the gadget should add the signature in the default way

--~~~~

not only

~~~~

as it is currently done. Deletion requests without a punctuation mark at the end look strange are hard to read (especially if a user name looks like a part of the sentence or an abbreviation, example). Other examples of today: 1, 2, 3, 4.

I am aware that there are users that have an individualized signature and that some of them do not want to have the two dashed added in front of it. So what about an opt-out feature that would work for all gadgets with an automatic signature? For example, SignatureWithoutDashes = true or similar. --Leyo 15:21, 4 July 2013 (UTC)[reply]

If we are going to add even more options, we should create a preferences-screen before. The script will be able to determine whether users have set a custom signature by invoking mw.user.options.get('nickname'). -- Rillke(q?) 15:30, 4 July 2013 (UTC)[reply]
A preferences-screen sounds like a good idea.
I for example do have a custom signature (default signature without talk page link), but I still would like to get the dashes. --Leyo 16:47, 4 July 2013 (UTC)[reply]

We had a similar problem at Wikidata (discussion), so I think an apposite MediaWiki preference (near those) would be a good idea.
Or, we could make dashes part of the signature by default:

  • the standard code would then be ~~~~ (without dashes)
  • the default signature would contain dashes
  • all custom signatures would not contain dashes by default
  • users that have custom signatures and would like to have dashes, would have to insert them before their custom signature in Preferences.

Any thoughts? --Ricordisamoa 23:11, 2 August 2013 (UTC)[reply]

I oppose adding the dashes into the default signature. Some users use author = ~~~ in Template:Information. They surely do not want to get dashes there.
What if the gadget uses --~~~~ for all users who do not have a custom signature? This relatively simple approach would not work in my case, but at least we would not have such “ugly” cases like the ones I linked above. --Leyo 22:35, 4 August 2013 (UTC)[reply]

User logs - Request

How can I log my use of AjaxQuickDelete? I used to do something similar on en.wp which I could then review my monthly deletions and I would like to be able to check my success rate or progress on speedy nominating copyvio etc. on Commons. -- (talk) 14:05, 9 August 2013 (UTC)[reply]

I ended up writing my own ad-hoc solution in Python, you can see my log as an example at User:Fæ/Mobiledeletions. It would be nice to see this as a standard user feature, in the same way that users have logging on en.wp. -- (talk) 13:56, 30 September 2013 (UTC)[reply]
This is in progress, together with opt-out for several tags or tag-groups. C.f MediaWiki talk:Gadget-Curator.core.js -- Rillke(q?) 16:07, 30 September 2013 (UTC)[reply]

Bug Dateiendung

Deutsch: Wenn ich Dateien auf den Commons verschiebe (ich habe das Recht zu verschieben), wird der Dateinamen außer meinen gewollten Änderungen in soweit - von mir nicht explizit gewollt - geändert, dass die Dateiendung (meist: jpg) von Großbuchstaben in Kleinbuchstaben geändert wird (Siehe auch de:Benutzer_Diskussion:Morty#Anregung). Da dies beim Hochladen nicht beachtet, bzw. die ursprüngliche Schreibweise behalten wird stufe ich das als einen unerwünschten Fehler ein. Entweder sollen alle Dateiendungen konsequent beim Hochladen (manuell oder Hochladeassi) auf "klein" geändert werden - oder die Umbenennungsfunktion lässt hier die Finger davon. Siehe auch de:Benutzer Diskussion:Raymond#Bug?

--Atamari (talk) 17:11, 13 August 2013 (UTC)[reply]

User_talk:Rillke/Discuss/2012/2#RenameLink_forces_case_in_file_extension // cleanFileName: // bugzilla:40326 // standard since nearly ever: Special:Permalink/43074737 // Please propose a code change in unified diff format and I will consider reviewing it as soon as I have time to. -- Rillke(q?) 17:34, 13 August 2013 (UTC)[reply]

{{Editprotected}} Please see Template talk:Delete#internationalisation of date. The date format is now changed: old transclusions will still work, but the new format allows for w:internationalization via {{ISOdate}}. Specifically, the "day" parameter should be in ISO format, as "YYYY-MM-DD". Later on, this argument could be changed to "date". --Ricordisamoa 16:17, 7 September 2013 (UTC)[reply]

PS: the "month" and "year" arguments should be omitted. --Ricordisamoa 16:19, 7 September 2013 (UTC)[reply]
Thank you. I will consider this in the rewite going on at MediaWiki:Gadget-Curator.core.js which will replace this gadget after a testing phase. -- Rillke(q?) 18:40, 7 September 2013 (UTC)[reply]
Deutsch: Fehlermeldung
Ein Problem ist aufgetreten

Beim Verschieben der Seite gab es einen Fehler. 
Folgend eine Detailbeschreibung des Fehlers:
API request failed (unknownerror): Unknown error: "backend-fail-synced" <i>at Tue, 10 Sep 2013 17:33:54 GMT</i> <u>served by mw1144</u>

--Knochen ﱢﻝﱢ‎  17:38, 10 September 2013 (UTC)[reply]

Daran können wir leider nichts ändern. Der Dateispeicher war für eine kurze Zeit ausgefallen und das hat zu nicht löschbaren und nicht verschiebbaren Dateien geführt. Weitere Informationen sind auf bugzilla:53838 erhältlich. Es dankt für diesen und den automatischen Feherbericht -- Rillke(q?) 20:08, 10 September 2013 (UTC)[reply]

error occurred while notifying the uploader

This error dialog appeared when I clicked the Nominate for deletion toolbox link on File:Bundesarchiv Bild 102-00418, Josephine Baker, Gemälde.jpg:

"An error occurred while notifying the uploader(s) of this file. Please follow the instructions on the deletion notice to complete the request.
A detailed description of the error is shown below:
API request failed (protectedpage): The "editprotected" right is required to edit this page Help: You can request an edit to 'User talk:BArchBot' at COM:AN (the Administrators' noticeboard). <i>at Sun, 22 Sep 2013 15:48:39 GMT</i> <u>served by mw1192</u>
The tag to be inserted into this page was {{delete|reason=How is this freely licensed? The painter died in 1980, therefore derivative works should be copyrighted until 2051. I see no evidence that the Bundesarchiv has the required permissions from the artist's estate to release this under a CC license.|subpage=File:Bundesarchiv Bild 102-00418, Josephine Baker, Gemälde.jpg|year=2013|month=September|day=22}}"

-84user (talk) 15:57, 22 September 2013 (UTC)[reply]

Load only if user has flag

I was wondering, does this gadget get loaded conditionally, depending on whether the user has the relevant permissions? mw.loader.inspect() told me that it loaded 43.9 KB on a file description page. I know one can disable it and that the parts depending on sysop/filemover flag are just a portion, I'm just curious. --Nemo 09:03, 19 February 2014 (UTC)[reply]

I am intending to care for that in my rewrite but I rarely find time to work on that. -- Rillke(q?) 09:20, 19 February 2014 (UTC)[reply]

update redirects - bugzilla:57057 - 1.23wmf16

Rillke(q?) 09:46, 25 February 2014 (UTC)[reply]

Naming mobile archives

Can the archive pages for mobile deletions please be grouped together under Category:MobileUpload-related deletion requests archives rather than its parent? There are so many now that they overwhelm the category first page. -- (talk) 11:10, 10 April 2014 (UTC)[reply]

Notice

there is no such button on the wiki-commons-page/pictures for german/deutsch — Preceding unsigned comment added by Selbsteiner (talk • contribs) 4 October 2014‎ (UTC)

Abort deletion nominations of Help:Nominate for deletion

A list of page ids where the procedure is aborted after showing the rationale-dialog (e.g.) for demo-purposes should be added. Help talk:Nominate for deletion#Please undo protection -- Rillke(q?) 15:18, 14 October 2014 (UTC)[reply]

wrong user notification

Here, not the uploader, but the uploader of the last file I nominated for deletion got notified.    FDMS  4    17:30, 6 November 2014 (UTC)[reply]
Next nomination, same issue: Special:Diff/138820749.    FDMS  4    17:51, 6 November 2014 (UTC)[reply]

Improvement request

Hi all, I'm moving this request from Commons:Village pump/Proposals.

I'm propose to improve the way copyright violations (Report copyright violation link in the left-hand menu) are handled by this gadget. What I'm proposing is that the reason provided by the person reporting the copyright violation (introduced by means of a text box with the title Why is this file a copyright violation?) is shown not only in the file page (which will be lost once the file is deleted) but also as part of the automatic notification left in the uploader page. It would help the uploader to understand what has gone wrong and, if suitable, to ask for an undeletion.

Best regards and many thanks into advance --Discasto talk | contr. | es.wiki analysis 23:33, 4 January 2015 (UTC)[reply]

{{Rename<space>|[...]}}

The removeTemplate function does not seem to expect a space (or newline) between the template name and the first pipe, which means that templates won't be removed in this situation. I noticed this in Special:Diff/163309649 and Special:Diff/163309670, where I found that I had to remove the template myself instead. --Stefan4 (talk) 19:52, 13 June 2015 (UTC)[reply]

It's still using a regular expression while it should use the WikiDOM JS parser. -- Rillke(q?) 20:16, 13 June 2015 (UTC)[reply]

"Nominate category for discussion" produces redlinks even though discussion page exists.

I've used the "Nominate category for discussion" option in the left sidebar on Category:Weidenbauwerke. On the category page, the this category's entry link of Template:Category for discussion is functional (leads here), but looks like a redlink. Since the same is true for the notification template on the talk page of the user who created the category, I'm assuming there's something wrong with the gadget rather than both templates? --El Grafo (talk) 10:18, 20 November 2015 (UTC)[reply]

The links to Commons:Categories for discussion/2015/11/Category:Weidenbauwerke at Category:Weidenbauwerke and the talk page look correct in my browser (i.e. blue, not red, links). Try clearing your browser cache and reloading the pages in question. The mediawiki software updates the database links table as a deferred job, so the status of a link can take a little while to be updated. —RP88 (talk) 10:45, 20 November 2015 (UTC)[reply]
Strange. I've cleared my cache multiple times and they're still red. Not only that, the urls also end with &action=edit&redlink=1 on mouse-over (or right click → copy address). When I actually click on them, everything's fine. Making a null edit just now fixed it for me. --El Grafo (talk) 11:17, 20 November 2015 (UTC)[reply]
I guess your user interface language is set to German. Each language version is cached by MediaWiki. So it's definitely possible that you see red links while others see blue links. -- Rillke(q?) 12:36, 20 November 2015 (UTC)[reply]
Nope, I've set the user interface to english years ago … --El Grafo (talk) 15:17, 29 March 2016 (UTC)[reply]
I as well see redlink to DRs and "This page is a member of Category:Incomplete deletion requests - missing subpage because...", almost each time I'm nominating files for deletion. I have a tool to purge pages and after I do purge, problem disappear. You can check Category:Incomplete deletion requests - missing subpage from time to time - it's not caused by users cache. --XXN, 14:58, 29 March 2016 (UTC)[reply]
I've observed that as well multiple times, but after refreshing the page (F5) usually everything's alright. Happens so often I don't really notice anymore. The stuff I described above was different in that only a null edit solved it for me (don't remember whether I tried using the purge button as well). --El Grafo (talk) 15:17, 29 March 2016 (UTC)[reply]
Mediawiki caches the contents of Category:Incomplete deletion requests - missing subpage in the database. If the deletion request is created after the file is tagged, then the page may incorrectly end up in Category:Incomplete deletion requests - missing subpage until the database cache is cleared. You can clear the cache by making a null edit to the file information page.
The HTML code of the file information page is also cached by Mediawiki, and this is done on a per-language basis, so information that a subpage is missing may be present in some language versions of the file information page but not in other language versions of the same file information page. You can clear the cache by appending ?action=purge at the end of the URL or by making a null edit.
IPs are more likely to see an outdated version than logged in users, I think. --Stefan2 (talk) 12:04, 31 March 2016 (UTC)[reply]
Thanks for the explanation, that seems to make sense. So maybe the gadget should create the DR/discussion pages before tagging the images? --El Grafo (talk) 14:23, 31 March 2016 (UTC)[reply]

Fail: maybe rare case to recognize the "original" uploader

Failed example → Commons:Deletion requests/File:Before and After..pngUser: Perhelion (Commons: = crap?) 14:48, 24 January 2016 (UTC)[reply]

|author=[[User:Hengistmate|Hengistmate]] should be honoured. This might be achieved with the new extended metadata feature or by simply parsing the file description and looking for Template["Information|...">param["author"]] and verifying it is a wiki link to a user page at Commons. -- Rillke(q?) 13:23, 27 February 2016 (UTC)[reply]
Can you also honour |author={{user at project|Example|wikipedia|qqx}}? I'm not sure if the notification needs to be at the local project. With SUL, it should be enough to notify the user on Commons, provided that the user has an account here (i.e. provided that the user has visited Commons while logged in). --Stefan2 (talk) 23:43, 28 February 2016 (UTC)[reply]

Minor-Bug summary (clickable section-title)

Just for retaining: The notification of users produce a false (anyway no clickable) section-title on (the second edit) the summary, if an autotranslate (or similar template or {{int:) is used.[1][2] (what appears to be always the normal case) There is an open general bug-report to this. An idea to fix would be an usage of the template:anchor (so the headline can anyway translated) and in the summary the default English title (as anchor)⁉ But this is not working too. User: Perhelion 13:28, 29 June 2016 (UTC)[reply]

Each template using Autotranslate should be fixed separately, eq.: Template:Image license -- User: Perhelion 19:04, 21 December 2017 (UTC)[reply]

Option to append templates

I would like to use the functionality of this script to add image cleanup tags where appropriate. However, I generally avoid adding cleanup tags like the script does since I don't think the cleanup tags are urgent enough to come before the image description, etc. I usually add them to the end of the summary section but appending them would be fine, too. Could an option to append rather than prepend tags be perhaps added to the AjaxDeleteExtraButtons options? —Quibik (talk) 16:21, 17 November 2016 (UTC)[reply]

Selecting and filling in reasons in move&replace

For filemovers & admins there should be an option to select reasons for edit summary when moving files which were not tagged for renaming by other users. ----XXN, 17:43, 5 January 2017 (UTC)[reply]

Not localized text strings

{{Edit request}} As seen, some text strings is not localized:

  1. Error messages:
    • 'The template does not expose a valid regular expression for {{X-To-DR}}. Go the the template and fix it there.'
    • "Unable to find the person who added the template. This can occur if the template was already removed, the page is deleted or a redirect to the template is used. In this case you must add the redirect to the RegExp of the target template."
    • " and the most recent rationale was: "
    • "Error in the duplicate-template, check your language version! (pg.imageinfo is undefined)"
    • "Retrieving information about " + pg.title + " failed. It is possible that it is deleted, the last revision is corrupt or the file is a redirect. (pg.imageinfo is undefined)"
    • 'The page you are attempting to add a tag to was deleted or moved. Unable to retrieve the content.'
    • "The page you are attempting to modify or move is corrupted, was deleted or moved: Unable to retrieve history and contents."
    • 'Checking file name: result.query.pages is undefined.'
  2. Another strings:
    • "Process Duplicates"
    • "[Process Duplicates]"
    • "This file does not qualify for [[COM:SPEEDY|speedy-deletion]] and a regular deletion request will be started."
    • "Listing "
    • "Listing mobile upload"
    • "Removing template; rename done" (this string was included in the past localizations as 'renameDone' variable)
    • 'Redirecting to duplicate file'
    • 'Merging details from duplicate'
    • "What-links-here" (?)
    • 'Updating redirect while processing'
    • "Updating redirects"
    • 'File renaming was recently declined, be prudent!'
    • 'rename request declined: does not comply with [[COM:FR|renaming guidelines]]'

If this is not be especially, maybe needs to convert these strings into translatable variables?

Also in the 'errorReport' value should be replacing text <tt>Report automatically</tt> to calling 'reportButtonLabel' variable. --Kaganer (talk) 07:56, 31 January 2017 (UTC)[reply]

Also text from MediaWiki:Gadget-AjaxQuickDelete.js/DiscussCategoryInfo should be included into localization array. --Kaganer (talk) 11:16, 20 December 2017 (UTC)[reply]

✓ Done Awesome! Thank you! PS: I removed some, because they are for summaries which should be on common files or discussions in project language. -- User: Perhelion 18:26, 21 December 2017 (UTC)[reply]

Cannot disable this gadget.

I have already unchecked it in Preferences, but the link still exists (and works) in the left "Tools" menu. --fireattack (talk) 08:43, 1 February 2018 (UTC)[reply]

Hey Fireattack, this is the most used and central gadget on Commons, it is needed by several other gadgets (as module and automatic loaded), like QuickDelete and RenameLink... (GalleryDetails, autodel seems not loading it but needs it) -- User: Perhelion 01:07, 12 February 2018 (UTC)[reply]
@Perhelion: : Understood that, but then its option should be removed from the preference. --fireattack (talk) 02:17, 12 February 2018 (UTC)[reply]
@Fireattack: I imagine you have some reason for wanting to disable it, would you care to explain? I find it extraordinarily useful, why don't you?   — Jeff G. ツ please ping or talk to me 06:29, 13 February 2018 (UTC)[reply]
@Jeff G.: I wanted to invoke the standard, non AJAX version "nominate for deletion" procedure, if there is one, because AjaxQuickDelete doesn't work with protected file (it will just stuck at step one, adding {{Delete}} to File page). But this is beside the point. In Help:Nominate for deletion, it says very clearly, "and can be deactivated in your Preferences". --fireattack (talk) 07:55, 13 February 2018 (UTC)[reply]
@Fireattack: The best way to get a protected page deleted is to discuss it at COM:AN. If the reasoning is sound and accepted, the page will then be deleted.   — Jeff G. ツ please ping or talk to me 14:15, 13 February 2018 (UTC)[reply]

timed text

{{Editprotected}} hi. can anyone update the gadget to move corresponding timedtext like here in video with renaming?--مصعب (talk) 23:38, 11 June 2018 (UTC)[reply]

Wrong number system

It seems that this tool sometimes uses the wrong number system for daily log pages for deletion requests. See for example Commons:Deletion requests/٢٠١٨/١٠/٢٧. Why does this happen? --Stefan2 (talk) 20:20, 27 October 2018 (UTC)[reply]

Hey Stefan, that seems a strange bug in the Date function (local client), called in MediaWiki:Gadget-libUtil.js formatDate. As we can see the date on the file entry is partial correct with Latin charset numbers Special:Diff/325571417 (Arabic numerals ironically). The script also doesn't recognize his own username as it's own (as he does notified himself). -- User: Perhelion 00:36, 28 October 2018 (UTC)[reply]
Maybe this is Android browser specific (as the other example uses also Android mobile App). At first the date gets from Gadget-libAPI.js (server date, per getResponseHeader). I don't know the point where the numbers get converted local (for testing, I have no real ambitions to change my system to Arabic). Maybe a MW technician can solve this easy. -- User: Perhelion 02:44, 28 October 2018 (UTC)[reply]

How to delete page from Wikimedia Data Namespace?

I want to delete my page Data:Moscowborders.ru/Crd/50-G.Serpukhovsky.map because it the same as Data:Moscowborders.ru/Crd/50-G.Serpukhov.map. I can not add {{delete}} template to this page, because API for map files checks JSON syntax and give "Syntax error". I can not use Nominate to delete link due to the same reason. Please help, how to delete? Nitobus (talk) 12:52, 1 February 2019 (UTC)[reply]

✓ Done deleted as duplicate. Not sure how you'd speedy nominate, but there was a pending deletion request, now closed. Rodhullandemu (talk) 12:58, 1 February 2019 (UTC)[reply]
Thank you. I have another similar request. I want to delete my page Data:Moscowborders.ru/Crd/50-G.Zvenigorod.map because it the same as Data:Moscowborders.ru/Crd/50-G.Odintsovsky.map. Can you please also delete it? Nitobus (talk) 13:14, 1 February 2019 (UTC)[reply]
✓ Done Deleted as duplicate. Rodhullandemu (talk) 13:21, 1 February 2019 (UTC)[reply]
Please also delete page Data:Moscowborders.ru/Crd/50-G.Likino-Dulevo.map‎ because it the same as Data:Moscowborders.ru/Crd/50-G.Orekhovo-Zuevo.map‎. Nitobus (talk) 19:24, 25 March 2019 (UTC)[reply]

Hi, I have this same issue of the delete template being incorrectly interpreted; however, it wouldn't be practical for this particular circumstance I'm working with, as I'm trying to phase out over a thousand, possibly two thousand maps I created for New Jersey and New York's road network, in favor of the Wikidata id system. Is there a more practical solution than having administrators deleting by direct request? Thanks, BMACS1002 (talk) 01:33, 24 August 2020 (UTC)[reply]

Replace usage: some usage not replaced

Thanks to 4nn1l2 for granting me the filemover right.

I almost immediately have a question: when I moved File:Jaap smit 2 (cropped).jpg, most of its usage was replaced but the use on w:en:King's Commissioner was not. I see no obvious reason why that page was skipped. - Alexis Jazz ping plz 14:38, 25 May 2019 (UTC)[reply]

It looks like this is happening to other users as well. Maybe @Perhelion: has an idea whay? --Steinsplitter (talk) 15:44, 25 May 2019 (UTC)[reply]
@Steinsplitter: which other users has it happened to? Perhaps it's because of the apostrophe? - Alexis Jazz ping plz 16:41, 25 May 2019 (UTC)[reply]
Happend to me multiple times, and i saw it in the delinker logs (pending replacement) that some files moved by others haven't been replaced. I am not sure if it is the apostrophe, maybe something with CORS or so. Dunno :/ --Steinsplitter (talk) 17:24, 25 May 2019 (UTC)[reply]
Filemovers can watch the progress of their overflow requests on User:CommonsDelinker/commands/filemovers.   — Jeff G. please ping or talk to me 17:34, 25 May 2019 (UTC)[reply]
I can look on this maybe next week, I've already an improved version local (for a while). -- User: Perhelion 12:28, 28 May 2019 (UTC)[reply]

✓ Done @Jeff G., Steinsplitter, and Alexis Jazz: I've changed the API from race to async, it should be much more reliable now. -- User: Perhelion 10:59, 21 September 2019 (UTC)[reply]

Edit request (convert-to-DR button for everyone)

{{Edit request}}

Per this vote, please remove admin/file mover check for the convert-to-DR button. - Alexis Jazz ping plz 10:48, 5 July 2019 (UTC)[reply]

@Jeff G.: that switch actually doesn't do anything in MediaWiki namespace. Not anymore. See Template talk:Edit request#Specific category for requests that require an interface admin. - Alexis Jazz ping plz 12:57, 5 July 2019 (UTC)[reply]
@Alexis Jazz: Sure it does something, it categorizes pages in this Mediawiki talk namespace into Category:Commons protected edit requests for interface administrators per this edit.   — Jeff G. please ping or talk to me 13:11, 5 July 2019 (UTC)[reply]
@Jeff G.: no, I wrote that and I think I know what my wikicode does. It categorizes this page into Category:Commons protected edit requests for interface administrators based on the namespace it's in. See, I removed the "technical=yes" and it's categorization didn't change. - Alexis Jazz ping plz 13:37, 5 July 2019 (UTC)[reply]
  • You can read the (very short) activation debate on COM:AN's history.
  • Why is there a restriction to file movers?
    • The deletion policy's advice that anyone who disagrees should convert was
      1. probably there before the technical scripting feature was created. Therefore, when you enable a new feature, you usually do so for experienced users who know where to report issues and how to undo damage done. Without the script, it is a little more tedious but of course possible to edit wiki pages :)
      2. IIRC challenged by some admins who heavily dealt with uploads of copyright violations.
  • Before enabling for everyone, I recommend
    1. Rephrasing the button's text to Challenge speedy deletion convert to ordinary deletion request or similar. Do not expect an ordinary user to understand what a DR is.
    2. Make the button translatable.
    3. Do not apply the same to the Remove this tag button for everyone.
  • Be aware that the script uses a hack to find the deletion template in Wiki text and might fail in case template names change.
  • Be aware the the entire script has many hacks and legacy code dependencies and might break at any MediaWiki update.

-- Rillke(q?) 14:03, 7 July 2019 (UTC)[reply]

How about enabling it for users with autopatrol and filemovers for now? And figure out how it can be translated etc. later?--Roy17 (talk) 14:38, 8 July 2019 (UTC)[reply]
You guys finish the discussion about whatever it is going to be. Maybe make a sandbox version in your user space for easy updating and when consensus has been reached, please add the {{Edit request}} without the tl part :-)
My recommendation is to only enable this at first for a limited number of users and maybe expand later. Multichill (talk) 16:43, 8 July 2019 (UTC)[reply]
We seem to have 2 different discussions about this going on simultaneously (and going in 2 different directions). Can we consolidate the discussion to Proposals#Enable convert-to-DR button for everyone? Kaldari (talk) 19:48, 11 July 2019 (UTC)[reply]

@Multichill, Roy17, Rillke, Alexis Jazz, and Jeff G.: I made a beginning. If we have more translation proposals I'll activate the button for autopatrollers. Maybe we should made the translations available per autotranslate or how we can made the translation more easier/obvious for users!? -- User: Perhelion 15:46, 8 September 2019 (UTC)[reply]

Please change the Chinese line to |yue=反對即刻刪除<br>改提刪除討論 |zh=反對快速刪除<br>改提刪除討論 |zh-hant=反對快速刪除<br>改提刪除討論 .
I made a mistake. LangSwitch is a template and each parameter has to be specified, unlike the magic word, switch.
We could put this question up on VP and get translations in most popular languages.
Then we could put a link in the gadget that tells users who want to add a new language to comment here.--Roy17 (talk) 16:09, 8 September 2019 (UTC)[reply]
@Perhelion: Thanks! Now, is there any legitimate use case for the "Remove this tag" button that can't be handled by undo or editing of wikitext? It seems like clickbait for people who won't take "no" for an answer.   — Jeff G. please ping or talk to me 16:23, 8 September 2019 (UTC)[reply]
@Jeff G: You mean the remove-button should also be visible for "everyone"? This is another question and seems not supported by the proposal. We will see what happens, so for now only one button (as the proposal).
@LangSwitch, Roy17: Thanks. It is also possible, the syntax seems undocumented Allow input in format: {{LangSwitch|de=Grün|es/it/pt=Verde|fr=Vert|en=Gree -- User: Perhelion 08:45, 9 September 2019 (UTC)[reply]
@Perhelion: Who is allowed to see the remove-button on a file marked with a speedy deletion request?   — Jeff G. please ping or talk to me 11:58, 9 September 2019 (UTC)[reply]
Admins and filemover. -- User: Perhelion 16:36, 9 September 2019 (UTC)[reply]
@Perhelion: Thanks, it's fine as-is then.   — Jeff G. please ping or talk to me 16:39, 9 September 2019 (UTC)[reply]
@Perhelion: may I ask whether this has been successfully enabled? I am an imagereviewer (implicit autopatroller) but I still dont see the button.--Roy17 (talk) 18:54, 9 September 2019 (UTC)[reply]
✓ Done Implemented! @Roy17 that's right, fixed!? -- User: Perhelion 19:50, 9 September 2019 (UTC)[reply]

Dual language messages

In order to improve the dialog with users that the language skills in English might be limited, I want to offer dual language messages. We can start with Hebrew first.

When I nominating files as No permission, No source, DW No source or NO fair use etc. the language of the message is according to the default language of the user. I believe that a lots of them did not changed it to Hebrew, therefore the are getting the message in English wich is not much helpful. I believe that dual messages in Hebrew and English would be better like I have did in User talk:טיפש ט"ו בשבט.

The bot that Steinsplitter operating in he.wiki tell me that users can be recognize by home wiki. Also Eran says:

It is possible to know the home wiki for a user through javascript using API query (example).
— User talk:Steinsplitter#Problem messages in Hebrew

So I think it would be good idea to make dual language messages start with Hebrew first. -- Geagea (talk) 14:15, 22 July 2019 (UTC)[reply]

 Oppose Although it would be technically easy to implement, I doubt its meaning. There are several techniques to solve exact this problem. The user must omit the user settings, the global settings, the top language button, AjaxTranslation links on the template, also as IP you get an automatic chosen language or you can also choose manually one. So the problem is very hypothetical, I think the language is not the problem for user ignorance. If we (redundant) extend this gadget to solve this, we declare the other methods wrongly to nonsense. -- User: Perhelion 14:19, 10 September 2019 (UTC)[reply]

Notifying File Importers

{{Editprotected}} We need to do this when imported files are in danger of deletion. Please see mw:Topic:V3ytxmfmk93xu7lg for details.   — Jeff G. please ping or talk to me 14:30, 22 July 2019 (UTC)[reply]

Hey Jeff G, I guess this is a false claim. Or you mean the original uploader? The importer should be already notified. Any example? -- User: Perhelion 12:24, 8 September 2019 (UTC)[reply]
@Perhelion: If @Geagea were not the second uploader of File:Shlomo lorentz.jpeg (and were just the Importer) and that file were to be tagged for deletion, that user would not be notified. We think they should be notified.   — Jeff G. please ping or talk to me 12:55, 8 September 2019 (UTC)[reply]
User: Perhelion, Look at my last import File:שילה פריד.jpeg. If this file will nominated I'll be not notified even though I am the actual uploader to Commons. I also think that some kind of template that gives the all the info saye something like: "This file was moved to Commons in DD/MM/YYYY by user:XYZ using FileImporter from en:File:ZZZZZ.jpg" or "This file originally uploaded to XX.wiki. It was moved to Commons in DD/MM/YYYY by user:XYZ using FileImporter from en:File:ZZZZZ.jpg". This at least, setting somehow the info about the history of uploading and importing of the file. -- Geagea (talk) 17:56, 8 September 2019 (UTC)[reply]
Oh* I see now what you mean, this is indeed a problem. I'll look what the script can do here. -- User: Perhelion 08:50, 9 September 2019 (UTC)[reply]
✓ Done Should be working now, just test it. (Tech background: But it needs an extra look in the log on every DR. The script looks normally in the imageinfo api for the uploads, not in the upload log, where the fileimporters are also visible. I think only because already deleted revisions can not recognized here.) -- User: Perhelion 18:59, 9 September 2019 (UTC)[reply]

Suggestion F10, F7, G10 and related tagging=

Hi. I use Ajax a lot to tag copyvios and its brilliant. Could this be expanded to tag Personal images, Corrupted files and adverts? At the moment we have to do this manually and also notify the uploader Gbawden (talk) 14:00, 31 July 2019 (UTC)[reply]

@Gbawden: Until that happens site-wide, you are welcome to copy my ajax extra buttons from User:Jeff G./common.js. Sadly, they only work in filespace. Of course, as an Admin here, you could dispense with tagging and just delete with good reason.   — Jeff G. please ping or talk to me 14:20, 31 July 2019 (UTC)[reply]
 Agree Good suggestions (also the direct related below topic), which could be easily solved. But personally I'm one month in vacation. -- User: Perhelion 10:49, 20 October 2019 (UTC)[reply]
Really enjoyed using User:Jeff G./common.js; slightly modified to be cleaner (User:~riley/CSD.js) - fully support more patrollers having access to these additional options. ~riley (talk) 05:01, 22 October 2019 (UTC)[reply]

Automatically tag G7

@Majora and Perhelion: I think I got something. If this is prepended to every DR, it should automatically tag G7.

{{subst:#ifeq:{{subst:REVISIONUSER}}| (replace this with the username of the uploader..findCreator or something?) |{{#ifexist:Commons:Deletion requests/{{FULLPAGENAME}}|{{#ifexpr: {{#expr:{{PAGEID}} + 180000}} > {{PAGEID:Commons:Deletion requests/{{FULLPAGENAME}}}}|{{void|G7}}}} }} }}

This is a cleaner version that requires an addition to {{Delete}}:

{{delete|yadda yadda{{subst:#ifeq:{{subst:REVISIONUSER}}| (replace this with the username of the uploader..findCreator or something?) |{{subst:!}}nominator=uploader}}}}

Prepend to {{Delete}}:

{{#ifeq:{{{nominator|}}}|uploader|{{#ifexist:Commons:Deletion requests/{{FULLPAGENAME}}|{{#ifexpr: {{#expr:{{PAGEID}} + 180000}} > {{PAGEID:Commons:Deletion requests/{{FULLPAGENAME}}}}|{{void|G7}}}} }} }}
  • "(replace this with the username of the uploader..findCreator or something?)" needs to be replaced with.. it speaks for itself.
  • I added "void|" to the G7 template so we can test this without disaster.
  • This code will add nothing if the nominator isn't the uploader.
  • A null-edit on the nominated page may be needed to "activate" the code. (deletion request may not yet exist when the page is parsed. adding
    {{void|{{Commons:Deletion requests/{{FULLPAGENAME}}}}
    to the nominated page would probably work as well)
  • There is no usage check. Admin remains responsible for that.
  • The date is estimated. Commons processes roughly 180000 revisions a week. Close enough for us, I think.

Any thoughts? - Alexis Jazz ping plz 18:40, 19 October 2019 (UTC)[reply]

Like I said, I'd be amenable to a sort of G7 autotagging as it would help eliminate unneeded DRs by people that don't know {{G7}} exists. But the use of an estimate like PADEIG + 180000 is disconcerting. I'd much rather have a bot do this. Krdbot already deals quite a lot with DRs. Perhaps Krd could be looped into this to see if this is a plausible extension of that bot? --Majora (talk) 18:49, 19 October 2019 (UTC)[reply]
@Majora: The 180000 seems quite constant. I thought this might be easier, more reliable (bots can malfunction sometimes) and quicker. (file would be tagged instantly) If Krdbot can do this, I'm happy with that too. A bot could be more precise. (check the exact date, maybe check some usage) - Alexis Jazz ping plz 18:54, 19 October 2019 (UTC)[reply]
Krdbot always seemed like one of the more well coded bots, and since its operator is active it would be able to be maintained in case of failure. Also, I like the potential to check for file usage as well (provided that can also be coded for). I don't have a problem testing this sort of thing if Krd doesn't want to, or cannot, extend the functionality of their bot. Just that I would rather try that route first. --Majora (talk) 18:58, 19 October 2019 (UTC)[reply]
Yes, it is more flexible. Also, I seem to have made a mistake: the 180.000 isn't as stable as I thought it was:
  • [3] (83214292, current)
  • [4] (83040206, 174086 since current)
  • [5] (82865074, 175132 since the above)
  • [6] (82632990, 232084 since last)
  • [7] (82399254, 233736 since last)
  • [8] (82162684, 236570 since last)
  • [9] (81952663, 210021 since last)
  • [10] (81781399, 171264 since last)
Am I doing something wrong? I wouldn't expect this to fluctuate this heavily. - Alexis Jazz ping plz 19:09, 19 October 2019 (UTC)[reply]
I don't know how the software determines revision id or if it is even sequential. I would imagine it would be but I can't say for sure. Also, how does it handle deletions? How does it handle oversighted material? If two people made an edit at the exact same moment who gets the lower value? Questions that would need to be answered to even begin to determine if you made a mistake in your calculations. --Majora (talk) 19:19, 19 October 2019 (UTC)[reply]
Oh, before anyone asks, it seems you can't do math on REVISIONID. Yeah, that would've been simpler. - Alexis Jazz ping plz 18:54, 19 October 2019 (UTC)[reply]

Suppress redirects option for file movers

{{Edit protected}}

Per Special:Diff/374178737#Adding a explanation and my own testing with my alternate account it appears that the "Leave a redirect behind" option is always checked for non-sysops even when the file is not in use. Since file movers now have the ability to suppress redirects perhaps the part of this code that blocks that should be tweaked. I do believe that it is line 268 that has to be tweaked.

From: if ( AQD.inUse || AQD.userRights === 'filemover' ) {

To simply if ( AQD.inUse ) {

Although please verify that assumption. --Majora (talk) 02:07, 11 November 2019 (UTC)[reply]

✓ Done Awesome! Thank you! Zhuyifei1999 (talk) 03:50, 15 November 2019 (UTC)[reply]

AbuseFilter support

The script currently does not support approving/dismissing AbuseFilter warnings. Maybe implement that in MediaWiki:Gadget-libAPI.js which already supports soft-catching exceeded rate limits by deferring those edits. -- Rillke(q?) 16:51, 8 December 2019 (UTC)[reply]

Exempt Help:Nominate for deletion from being able to be DR'ed

If possible could an exemption be added to this script that rejects attempts to DR Help:Nominate for deletion. Per the page's history this appears to be a problem however the page also has a tutorial which is rendered inoperable if the page is protected. The only other option would be to add a if statement to the script itself that rejects attempts to DR that page. --Majora (talk) 00:46, 2 February 2020 (UTC)[reply]

Gadget is critically broken

{{Edit protected}} I just pressed the "Remove this tag" button at File:Pintail (male) - Las Galinas WWTP - Marin - CA - 2015-10-22at12-30-532 (22187340423).jpg, and the tool used my account to delete the file. That's a pretty critical malfunction right there. I double-checked in case it was a one-off glitch. Succeeded in deleting File:Northern shoveler 690V5185 - Flickr - Lip Kee.jpg by pressing the "Remove this tag" button multiple times. Hesperian 00:20, 13 February 2020 (UTC)[reply]

Unclear why this topic was tagged with edit protected because it doesn't contain a request to edit anything. Multichill (talk) 13:26, 7 August 2020 (UTC)[reply]

Very long filenames should be abbreviated

{{Commons:Deletion requests/File:Vertrek vanaf Huis ten Bosch voor de doop van prins Willem Frederik, 1772 Afbeelding van het afryden met den Jonge Erfprins, na den H. Doop, van het Huis de Oranje-Zaal, op den 17den September 1772 (titel op object), RP-P-OB-84.817.jpg}} does not transclude, since (with URL-encoded spaces), the filename is over 255 characters. Replacing spaces with underscores does allow it to transclude, but in general, filenames over 255 characters should probably be truncated. Storkk (talk) 11:02, 4 May 2020 (UTC)[reply]

Autoreporting by IP users

The autoreport function doesn't sign properly for anonymous users, which uses their nonexistent userpage instead of their contributions page (which is what ~~~~ uses). Due to this, SignBot thinks that the report is not signed, even though it is. I don't want to bother Zhuyifei1999 to make his bot ignore the autoreports page, so can you guys fix it instead? pandakekok9 12:10, 14 May 2020 (UTC)[reply]

error: cant start deletion discussion AntiCompositeBot

Dear all,

AntiCompositeBot flagged File:Johannes Colerus - Korte, dog waaragtige Levens-beschrijving, van Benedictus de Spinosa, Amsterdam, 1732, p 144.jpg because of a format error in the permission PD-old-100-1923. I can't open a deletion discussion there and i was invited to report the error here. Thanks, Hansmuller (talk) 07:41, 28 June 2020 (UTC)[reply]

Technical error with the file mover gadget.

There is some sort of problem with the file mover element of the gadget, in which it is altering or deleting characters in a proposed file name. I attempted to report this to Phabricator, but was told that this is the appropriate place to raise the issue. This problem can be seen in the several attempts I made at renaming File:New Zealand road sign W1-1A + W1-1A.svg.

The desired file name is "New Zealand road sign W1-1A + W1-1.4A"

  • In my first attempt, the file was moved to "New Zealand road sign W1-1A + W1-1.4a", with the gadget altering the final letter to lower case.
  • In my second attempt, the file was moved to "New Zealand road sign W1-1A + W1-1", with the gadget deleting deleting ".4A" at the end of the file name.
  • In my third attempt, the file was moved to "New Zealand road sign W1-1A + W1-1A", with the gadget deleting deleting ".4" at the end of the file name.

Fry1989 eh? 20:08, 5 November 2020 (UTC)[reply]

Error while moving the page

I've failed to move the file File:Varonča, Niesiałoŭski. Варонча, Несялоўскі (1901-14) (1).jpg under the name File:Varonča, Niesiałoŭski. Варонча, Несялоўскі (1901-14).jpg. Every time the following error occurs: Error while moving the page. A detailed description of the error is shown below: API request failed (backend-fail-synced): The file "mwstore://local-multiwrite/local-public/4/48/Varonča,_Niesiałoŭski._Варонча,_Несялоўскі_(1901-14).jpg" is in an inconsistent state within the internal storage backends at Wed, 16 Dec 2020 18:27:39 GMT served by mw1317. Could you please help me to fix it? --Kazimier Lachnovič (talk) 18:37, 16 December 2020 (UTC)[reply]

Got the same error trying to move the file File:Barysaŭ, Aršanskaja. Барысаў, Аршанская (1910) (1).jpg under the name File:Barysaŭ, Aršanskaja. Барысаў, Аршанская (1910).jpg. --Kazimier Lachnovič (talk) 19:52, 19 December 2020 (UTC)[reply]
Got the same error trying to move the file File:Mahiloŭ, Školišča, Chałodnaja synagoga. Магілёў, Школішча, Халодная сынагога (1901-18) (3).jpg under the name File:Mahiloŭ, Školišča, Chałodnaja synagoga. Магілёў, Школішча, Халодная сынагога (1901-18).jpg. --Kazimier Lachnovič (talk) 17:41, 19 July 2021 (UTC)[reply]

Error when trying to nominate template for deletion

I tried to nominate {{Swisstopo}} for deletion using the script, but got an "API request failed (abusefilter-warning): ⧼abusefilter-warning-otrs⧽ at Sun, 07 Mar 2021 15:52:10 GMT served by mw1347" error message. In the text of the nomination, I had a link to an OTRS ticket, maybe that is the cause? Here is the full error message with the text I tried to insert:

An error occurred while trying to do the requested action. To nominate this template for deletion, please edit the page to add the {{delete}} template and follow the instructions shown on it. A detailed description of the error is shown below: API request failed (abusefilter-warning): ⧼abusefilter-warning-otrs⧽ <i>at Sun, 07 Mar 2021 15:52:10 GMT</i> <u>served by mw1347</u> The tag to be inserted into this page was {{delete|reason=Switzerland used to have a special non-copyright restriction for "Geobasisdaten" which was discussed in [[Commons:Deletion requests/File:Kanton Basel-Stadt 1836.jpg|this deletion request]] in 2016 and led to the creation of this template which was, however, only ever used for that single [[:File:Kanton Basel-Stadt 1836.jpg]] (I removed it there now). In effect per March 1, 2021, to [https://www.srf.ch/news/schweiz/luftbilder-und-modelle-digitale-geodaten-von-swisstopo-kostenlos-und-frei-nutzbar much media fanfare], the GeoIV act was amended (new article 28a), and current as well as historical map data are now freely available and usable (even commercially). Per Swisstopo's [https://www.swisstopo.admin.ch/en/swisstopo/free-geodata.html#286_1584718316416 FAQ] (availbale in English), explicit permission is no longer needed: ''Is authorisation necessary to use swisstopo geodata? No, no authorisation is required. However, the source must be indicated upon use as “Source: Federal Office of Topography swisstopo” or “© swisstopo”.'' There is now a template {{tl|Attribution-Switzerland-mapdata}} for that. It should be used for current (copyrighted, but freely usable) map data and I think, if people want to be especially cautious, it could also be added to historical public domain maps, as the non-copyright based restriction that attribution is mandatory might still apply to these. A ping to [[User:O.Koslowski|O.Koslowski]] as the creator of the original deletion request (maybe you can add this new information to the [https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom&TicketNumber=2016031810015237 OTRS ticket] as I don't have OTRS access) and to [[User:Ankry|Ankry]] who created that IMHO now obsolete template.|subpage=Template:Swisstopo|year=2021|month=March|day=7}} Gestumblindi (talk) 15:58, 7 March 2021 (UTC)[reply]

I've now created the deletion request successfully by leaving out the link to the OTRS ticket. Is there any particular reason for filtering out such links in deletion requests? Gestumblindi (talk) 16:00, 7 March 2021 (UTC)[reply]
Well, I think I see now what happened. MediaWiki:Abusefilter-warning-otrs is intended to prevent adding OTRS tags to pages, which of course should only be done by OTRS members, but apparently in this case, it also caught merely linking to an OTRS ticket in starting a deletion discussion. This is not intended behavior, I think, and probably should be changed, but I don't know how - will report it at MediaWiki talk:Abusefilter-warning-otrs. Gestumblindi (talk) 16:04, 7 March 2021 (UTC)[reply]

Add a newline after CfD template

{{Edit request}} When nominating a category for discussion, this Gadget prepends {{subst:cfd}} but it doesn't add a line return after it. This has almost caused me to delete the first line of page content several times when removing CfD templates. To fix this, I think line 442 should be changed to this.tag = '{\{subst:cfd}}\n';BMacZero (🗩) 22:30, 23 June 2021 (UTC)[reply]

✓ Done, hopefully, please try it out :) --Lucas Werkmeister (talk) 19:41, 22 September 2021 (UTC)[reply]
@Lucas Werkmeister: Thanks! It looks good me in this edit. – BMacZero (🗩) 05:32, 23 September 2021 (UTC)[reply]

TypeError thrown after recent changes

@Krinkle: Since (I think) this edit, I'm getting Uncaught TypeError: $(...).html(...).dialog is not a function thrown from line 1919 when using the "Move" function on a file description page (not a +sysop or filemover). It looks to me like $.ui is not defined at this point, in spite of the mw.loader.using(['jquery.ui']) it's wrapped in, but my JS debugger-fu isn't quite up to being sure there.

What's weirder is that it seems to be somehow dependent on the file. I never hit this on plain image files (I randomly picked ~15 recent .jpg and .svg files out of the RTRC feed), and not on PDF files (randomly picked out of Category:Books (literature) in PDF). On DjVu files I hit it on most of the files I tested, but then randomly one DjVu file worked fine. It does not obviously appear to be related to the amount of metadata (number of pages in the file, size of the hidden text layer / OCR in the file).

My main test case that fails is File:The English Works of Thomas Hobbes (1845), Vol. 8.djvu (feel free to move this to "… (1843) …" btw), and the file that seemingly-randomly doesn't throw is File:Sibu Congkan0066-許慎-説文解字-4-1.djvu.

I also can't swear the referenced change is when this started happening. I don't request renames daily; but often enough that it's exceedingly unlikely to be the September 2020 changes that caused it. I suppose it could be triggered by the changes in T275268 (CC Ladsgroup), but I can't quite see how that would lead to jquery.ui not getting loaded, iff that's what's happening.

Tested in recentish Safari, Chrome, and Firefox; but obviously only when logged in. Both AjaxQuickDelete and RenameLink gadgets are enabled. Xover (talk) 10:23, 14 July 2021 (UTC)[reply]

Oh, and cf. this issue, the above is when trying to use the move function from the actual file description page, not in edit mode or history.
But it occurs to me that the "Move" portlet is added by MediaWiki:Gadget-RenameLink.js, which calls AjaxQuickDelete.showProgress(…) without loading jquery.ui anywhere. And neither one of these have jquery.ui as a dep in MediaWiki:Gadgets-definition (insert obligatory rant about the status quo for JS UI stuff in MW here). Could this simply be timing-dependent? On some files any number of factors could lead to jquery.ui getting loaded on page load, but for those that don't RenameLink's startAndLoad() calls straight into .showProgress() bypassing the mw.loader.using(). Or…? Xover (talk) 10:46, 14 July 2021 (UTC)[reply]
Oh. The plot thickens. D'oh! Yeah, it seems the only mystery is why this doesn't fail on most files I tested. MediaWiki:Gadget-RenameLink.js bypasses the mw.loader.using() you added to MediaWiki:Gadget-AjaxQuickDelete.js by calling directly into AjaxQuickDelete.showProgress(…). So the fix would be to wrap that call in mw.loader.using(["jquery.ui"]).then(…). Xover (talk) 12:00, 14 July 2021 (UTC)[reply]
@Xover Fixed in edit. Thanks --Krinkle (talk) 15:31, 14 July 2021 (UTC)[reply]
@Krinkle: Thanks! I just verified that it fixed the issue here. Xover (talk) 15:39, 14 July 2021 (UTC)[reply]
@Xover The image refactor shouldn't change anything user facing and we haven't done anything on djvu (except general php ->json refactor but that's for all media not just djvu) Amir (talk) 12:06, 14 July 2021 (UTC)[reply]

Stopped working in gu.wiki

I have had this gadget copied and enabled in gu.wiki here and it was working up until few months back. I copied the latest from here and updated my local .js file there on gu.wiki, since then it has stopped working. Will appreciate if someone can have a look and advise/help on the fix.--Dsvyas (talk) 13:56, 3 December 2021 (UTC)--Dsvyas (talk) 13:56, 3 December 2021 (UTC)[reply]

Expand "More info" for registered users

it'll be a good idea to display some common alternatives to starting a "discussion".

for example, if they want to rename a file or a cat, just use rename.

if they want to delete an incorrectly named cat, use {{Badname}}.

etc.--RZuo (talk) 15:56, 30 January 2023 (UTC)[reply]

If a page only allows editing through the translation interface the Delete button should not be displayed

If three buttons are displayed on this page, an error will be reported after three buttons are mentioned. Q28 (talk) 12:24, 17 April 2023 (UTC)[reply]

File moving error

Dear all,

when moving files I have had 4 error reports already, and it refuses to rename the 4 different files, where I never had an error before. After repeated tries all but 1 have been renamed now. Error message:

API request failed (internal_api_error_DBQueryError): [0d936a38-2476-4725-9560-1d411482eab2] Caught exception of type Wikimedia\Rdbms\DBQueryError at Mon, 22 May 2023 06:12:32 GMT served by mw1450

Sincerely, Taketa (talk) 06:15, 22 May 2023 (UTC)[reply]

@Taketa: This is a bug in MediaWiki, not the gadget. If you still experience it, please report it on Phabricator. —Tacsipacsi (talk) 23:25, 23 May 2023 (UTC)[reply]

Improvement related to file moving

  1. when filemover clicks "Move file and replace all usage", can the popup default display the full version? or at least make it a setting? quite often i wanna switch the criterion. it's annoying i have to click the tiny expand button each time.
  2. MediaWiki:Gadget-AjaxQuickDelete.js#L-383 "TODO extend the reason (for summary)". instead of a single boilerplate, provide more specific reasons corresponding to the request criterion.
  3. add moved/declined pages to watchlist with 1 month expiry. (further: make the duration a setting.)
  4. instead of relying on Commons:File renaming/Recently declined rename requests (which is set to only 3 days now), maybe check page history for edit summaries containing "declined"?
  5. since so many things could be changed about the file moving function, maybe spin off a gadget only for filemove?

RZuo (talk) 12:31, 15 June 2023 (UTC)[reply]

No rvslots deprecation warning

The query to api.php?format=json&curtimestamp=1&prop=info|revisions|imageinfo&meta=tokens&rvprop=content|timestamp&inprop=watched&titles=...&iiprop=mediatype|mime|timestamp&action=query&_=... causes the api to emit the following warning:

   Because "rvslots" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used.

Platonides (talk) 01:41, 27 August 2023 (UTC)[reply]

Change "nominate" to "mark"

It is requested that an edit or modification be made to this protected page.
Administrators: Please apply <nowiki> or {{Tl}} to the tag after the request is fulfilled.

RZuo

Change all strings that say something similar to "nominate" to "mark" for consistency with MediaWiki talk:Pagetriage-button-mark-for-deletion. Aaron Liu (talk) 20:20, 27 November 2023 (UTC)[reply]

i agree with your initial suggestion to change MediaWiki:Pagetriage-button-mark-for-deletion. "nominate" sounds more suggestive and open for discussion than "mark". RZuo (talk) 22:04, 29 November 2023 (UTC)[reply]