Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Community portal
Help deskVillage pump
Administrators' noticeboard
vandalismuser problemsblocks and protections

Shortcut: COM:VP/P· COM:VPP

Welcome to the Village pump proposals section

This page is used for proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{section resolved|1=~~~~}} may be archived; for old discussions, see the archives.


Please note
  • One of Wikimedia Commons’ basic principles is: "Only free content is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing.
  • Have you read the FAQ?


SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.

Proposal typing aid[edit]

When somebody uses e.g. the de:WP it should be well known that there are many 'search' abbreviations; as an example, H:T will make some suggested expansions, like Hilfe:Tabellen, or H:V like Hilfe:Vorlagen. That simplifies the access to many pages - not only to Help pages.
Spoiled by such comfort, I am missing a comparable service in the commons, where I am doing a lot. On busy days I type hundreds times the long namespaces Template: or Category:, wishing it would as well be possible with only T: or C:. To install such a possibility could not be a problem to the relevant people!
In the English language, many terms are pleasantly short (Help, File, User); really longs things are abbreviated (i18n); I just miss the mentioned cases - therefore I ask the community about that idea. -- sarang사랑 15:07, 16 June 2019 (UTC)

@Sarang: C: is not desirable because this is the recommended interwiki code for Commons. We have COM:, templates can be linked with {{Tl}} and when using templates you don't usually need to enter Template:. See also COM:Shortcuts. - Alexis Jazz ping plz 16:20, 16 June 2019 (UTC)
Thank you. Ok, C: is not desirable, I understand that it is the wrong example. But when I want to enter a special template, or category, I always have to type the full namspace: first. I know that we have short-named templates, like {{C}}, {{F}}, {{T}}, {{U}}. But that's only for using/linking them - not for searching. -- sarang사랑 16:41, 16 June 2019 (UTC)
I opened a Phab ticket a while ago for "Have searchbox recognize {{ to search Template: namespace". DMacks (talk) 13:09, 30 August 2019 (UTC)
  • Symbol support vote.svg Support aliases T for template, CAT for category, and MOD for module. 4nn1l2 (talk) 20:21, 16 June 2019 (UTC)
    @4nn1l2: I think T could be risky with possible future interwiki shortcuts. - Alexis Jazz ping plz 20:28, 16 June 2019 (UTC)
    @Alexis Jazz: I guess that is the problem of future, not now. In my opinion, WMF already hosts too many projects, and new projects should not be added too easily, and I guess we have not had a new project for many years (excluding Wikidata). 4nn1l2 (talk) 20:42, 16 June 2019 (UTC)
  • Symbol support vote.svg Support the aliases mentioned by @4nn1l2, plus U for User, F for File, and T suffixes for associated talk namespaces (UT for User Talk, GT for Gallery Talk due to conflict with Template).   — Jeff G. please ping or talk to me 20:33, 16 June 2019 (UTC)
  • Symbol support vote.svg Support - Why not ? I'm too lazy to write the full word. -- Eatcha (talk) 10:29, 18 June 2019 (UTC)
  • I only support t for template and cat for category. Inclined to oppose the others. Use shorthands only for the most frequent words.--Roy17 (talk) 19:02, 18 June 2019 (UTC)
  • Symbol support vote.svg Support.--Vulphere 10:02, 20 June 2019 (UTC)
  • Symbol support vote.svg Support, but with reservations, mostly because of the multilingual nature of Wikimedia Commons, we should try to support as much language as possible while trying to avoid confusion while implementing this. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:14, 21 June 2019 (UTC)
  • Symbol support vote.svg Support CAT for categories would be very useful --Ruthven (msg) 14:31, 13 July 2019 (UTC)
  • Symbol strong support vote.svg Strong support. -- 06:14, 25 August 2019 (UTC)
  • Symbol support vote.svg Support for sure. In addition to what @4nn1l2 mentioned above, I think UT for user talk can be very useful as well. Ahmadtalk 17:56, 21 September 2019 (UTC)
  • Symbol strong support vote.svg Strong support Masum Reza📞 21:31, 21 September 2019 (UTC)

Addition to COM:OVERWRITE: no image optimizer tools[edit]

To ✓ Minor improvements, add:

✘ The same file with no change but a reduced file size using tools like PNGOUT, pngcrush, jpegoptim, etc.

I occasionally see users doing this, thinking its useful. For any thumbnail (most on-wiki use) it makes no difference so it saves little bandwidth, does cost some storage, browser compatibility (especially for SVG files) can be altered, metadata and color profiles could be lost, compression is not guaranteed to be lossless and because those users do this by hand, they could be introducing all kinds of errors. If we actually wanted it, we'd have a bot for it or even just have MediaWiki do it automatically. No user should do this by hand. - Alexis Jazz ping plz 01:58, 25 July 2019 (UTC)

No image optimizer tools: votes[edit]

  • Symbol support vote.svg Support as proposer. - Alexis Jazz ping plz 01:58, 25 July 2019 (UTC)
  • Symbol support vote.svg Support, how is this not considered a form of vandalism? (just to be clear, I don't support ever blocking someone over this, people often do it in good faith, but if partial blocks will one day be implemented then I would support limiting WARNED repeat offenders from doing this.) Maybe when someone overwrites an existing file there should be a list of rules displayed like we have for renaming an existing file. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:24, 25 July 2019 (UTC)
  • Symbol support vote.svg Support as reduction of file size is not good in the most cases in general --GPSLeo (talk) 17:36, 25 July 2019 (UTC)
  • Symbol support vote.svg Support.   — Jeff G. please ping or talk to me 17:48, 25 July 2019 (UTC)
  • Symbol support vote.svg Support.--Vulphere 06:14, 26 July 2019 (UTC)
  • Symbol support vote.svg Support That kind of "optimization" doesn't really seem to help anybody as a) it only increases the storage space used over all and b) the user gets served png thumnails that have been rendered server-side anyway. --El Grafo (talk) 07:27, 26 July 2019 (UTC)
  • Symbol oppose vote.svg Oppose The proposal is much too general and should more specific to a global restriction. E.q. file-format, SVG, s. below or if the optimized file is 3/4 smaller (or other) -- User: Perhelion 00:26, 11 August 2019 (UTC)
  • Symbol oppose vote.svg Oppose I'm unconvinced this is a problem that needs fixing. If you see someone doing something that you consider to be a waste of time, perhaps let them know... but I struggle to see why this is something for which we need to create a rule. Also, there are situations where a file is perversely huge for no good reason - on the other hand, maybe we should just delete them. Storkk (talk) 09:35, 13 August 2019 (UTC)
  • Symbol oppose vote.svg Oppose per Perhelion and Storkk. -- Begoon 14:56, 28 September 2019 (UTC)

No image optimizer tools: discussion[edit]

  • Pictogram voting comment.svg Comment altering browser compatibility for SVG can be a good thing if it fixes some of the many commons issues … --El Grafo (talk) 09:40, 25 July 2019 (UTC)
  • Pictogram voting comment.svg Comment It seems most people here have no real clue about the SVG format. A general restriction is absolute senseless here. Some SVG are full of code garbage (e.q. 4 MB vs 40 KB, which can have huge performance impact and can crash the Mediawiki renderer) and that's one of the main points why SVG is not natively support here (not the compatibly issue). phab:T208578 -- User: Perhelion 00:07, 11 August 2019 (UTC)
    • @Perhelion: You misunderstood the proposal. Some further explaining can be added to COM:OVERWRITE though. If you overwrite some 4 MB SVG file with a 4 KB one to stop the Mediawiki renderer from crashing or browser from locking up, you have overwritten it for those reasons. Not to reduce the file size. If a 4 KB SVG is crashing the Mediawiki renderer, you'd also overwrite it. Not crashing the Mediawiki renderer is a change different from reduced file size, so you can overwrite. Removing junk that makes the file hard to edit, thus making it easier to edit, is also a change different from reduced file size. - Alexis Jazz ping plz 07:41, 13 August 2019 (UTC)
      • By that logic, any size reduction of (non-png) files would make them easier to edit. And that change may not be trivial if the edits are being done in bulk (for raster) or by hand (for SVG). Some common sense is always going to be necessary, no matter how many rules we create. Some people are always going to occupy themselves in ways that others think are trivial, and while it may be OK to point out to them why you think that work is trivial or useless, I can't fathom why you'd want to enshrine a prohibition in the guideline. Storkk (talk) 07:54, 14 August 2019 (UTC)
        • @Storkk: "I struggle to see why this is something for which we need to create a rule." I've had to deal with several of them. I felt it would be rather inappropriate to name and shame them. One of them was particularly annoying, and without a rule to point to they fail to see why they are harming the project. And no, not "any size reduction of (non-png) files would make them easier to edit". Reducing a .jpg by 2% does not make it easier to edit. - Alexis Jazz ping plz 09:26, 23 August 2019 (UTC)
          • Wait a second... how exactly are they "harming the project"? Storkk (talk) 09:31, 23 August 2019 (UTC) @Alexis Jazz: (courtesy ping) Storkk (talk) 09:32, 23 August 2019 (UTC)
            • @Storkk: Your ping didn't arrive. I think it has to be on a new line. When they upload an SVG that's turned into unreadable high density rubbish, any user who tries to create a derivative work from that is harmed. (happened to me) When they "optimize" files and it's not lossless, they harm those files. (seen it) When they accidentally swap files when overwriting (because this shouldn't be done by hand), they harm the project. And these things are done for.. no gain whatsoever. - Alexis Jazz ping plz 09:51, 23 August 2019 (UTC)
              • @Alexis Jazz: Thanks - I didn't know that; I thought it just needed to be signed. I believe all of the above fall afoul of policies and guidelines we currently have. Storkk (talk) 10:41, 23 August 2019 (UTC)
                • Maybe this should be about optimizing bitmap images in particular. SVG would be more nuanced, for sure. I have had some of my SVG uploads optimized -- quite legitimately, as the older converter I was using resulted in a needlessly huge file. I have also seen some silly re-uploads of SVGs just to make the file size a tiny bit smaller (even sometimes removing invisible elements that aid in positioning/editing, just to make it smaller). On the other hand, there could be valid changes to make an SVG more readable when editing by hand, or optimizing some of the drawing commands for faster rendering. The rules there should be more nuanced, as some are hand-editable (and thus have readability concerns), and don't have the "lossless" problems that bitmaps do. Carl Lindberg (talk) 15:18, 23 August 2019 (UTC)
                  • As usual, this requires a modicum of common sense and understanding what one is doing: two things that are virtually impossible to ameliorate by creating hard rules. There are very legitimate reasons for potentially reducing filesizes for simple raster images: poor default settings can lead to immense filesizes which can be reduced (often 20 fold or more) by simply using indexed colors and judicious recompression. I have personally experienced this frequently when including screenshots into a PDF produced using LaTeX... losslessly converting the PNGs to indexed color reducing the PDF from dozens of megabytes (quite hard to email) to hundreds of kilobytes (easy to email and share). We should not (IMO) have a prohibition on a step that frequently makes our media easier to re-use without damaging quality, regardless of how frequently this step is also mis-used. Storkk (talk) 16:45, 23 August 2019 (UTC)
                    • Those are fair points. The rule though is more about smaller optimizations like pngcrush, jpegoptim, etc., so uses well outside those areas would still seem to be reasonable. Maybe it should read "The same file with no change but a slightly reduced file size"... but it's possible it would need to be more carefully worded than that too. I know I have overwritten to remove an image profile which prevented display in many browsers. And there could be images with outsize resources internally mostly unrelated to display (excessive thumbnails or metadata or something). Carl Lindberg (talk) 17:26, 23 August 2019 (UTC)
                      • Assuming that the overwrite only slightly reduces filesize, and that it does not have an otherwise deleterious effect that is already prohibited by policy & guideline, I'm back to struggling to see the harm. This whole endeavor (the wikipedias as well as commons and other sister projects) is built on thousands upon thousands of people making small incremental changes that many people would consider trivial. Granted, I personally agree that these particular edits (again, assuming no deleterious effects already prohibited) can be close to pointless... but until I see the actual harm I can't endorse this. Storkk (talk) 18:48, 23 August 2019 (UTC)
                        • It creates another copy of the file, which uses added space. The old file is still stored (though without being able to see its metadata on the file page); we just add a slightly smaller version on top. I mean, if someone changes an 85MB PNG to 82MB with pngcrush, that is a fair amount of storage that is more or less wasted. Oftentimes those tools may accidentally strip some metadata on the way, etc., or may not be lossless. It's somewhat easy to make mistakes with command line arguments, too. Jpegtran has some modes which are not lossless. Reducing the file size significantly (if lossless) is a good thing, but a marginal reduction usually doesn't help much if at all, and just adds more copies of the file to be stored. Using pngcrush etc. just to squeeze a few more bytes out should be discouraged, I think. If it reduces from 85 to say 10 somehow, well that's different. Not sure the best way to get that into the guideline, but this seems reasonable. This is a guideline, not (hard rule) policy. And it would be listed in the "minor improvements" area, whereas the ones that you describe seem far from minor. Carl Lindberg (talk) 19:05, 23 August 2019 (UTC)
  • @Storkk: For another example, see File:Donald Trump official portrait.jpg. This was compressed lossy. An example of just being silly: File:Lichtenstein jpeg2000 difference.png was reduced from 394KB to 391KB. Totally worth it. (luckily this user was very understanding when this was explained)
@Storkk, Perhelion, Clindberg: What if the proposal was adjusted to be a bit more precise:
✓ Lossless file size reduction of at least 50% while preserving all metadata, color profiles and software compatibility. Vector graphics (e.g. SVG) only: the same, but highly generic metadata may be removed, code readability has to be preserved and invisibile guide elements should also be preserved.
✘ File size reduction overwrites that do not meet all those requirements should not be performed without community consensus.
Would that be better? - Alexis Jazz ping plz 20:58, 1 September 2019 (UTC)
Still feels like creating rules for the purpose of creating rules, and I am extremely skeptical that the creation of this rule will be a net benefit to the project. But it appears I'm in the minority. Storkk (talk) 08:27, 2 September 2019 (UTC)

Allow file movers to suppress redirects[edit]

Give file movers the suppressredirect right and adjust MediaWiki:Gadget-AjaxQuickDelete.js to let them use it to suppress redirects while moving files, to avoid the situation described at Image name swap request.   — Jeff G. please ping or talk to me 14:40, 21 August 2019 (UTC)

  • Symbol support vote.svg Support Obviously, given my comments at AN. As I said there, that this is not available on Commons currently almost seems via technicality, as we have no page mover right, and therefore no user right with suppressredirect un-bundled from the sysop toolkit, while other large projects do. I understand that we don't normally want to suppress redirects at all, and this would, I imagine, mostly be used in the case of round-robin moves (a to c, b to a, c to b). In these cases it seems simple enough just to have some template saying that a redirect was suppressed/the file renamed and replaced. Guidance may need to be updated in that respect, although the current guidance (These redirects should almost never be deleted.) seems fairly straightforward. Even so, we have seven times more file movers than we have sysops, and it seems that someone who is experienced enough to understand the comparatively complex criteria for moving files should be competent enough to know whether suppression is necessary. GMGtalk 14:58, 21 August 2019 (UTC)
  • Symbol support vote.svg Support but I'd suggest having a new user right like "extended file mover" or something on the line just to be safe. (Talk/留言/토론/Discussion) 15:02, 21 August 2019 (UTC)
  • Symbol support vote.svg Support - I too have occasionally had to do moves like this and it's frustrating having to rely on an admin to do it (I could apply to be an admin but I prefer a non-admin easy life tbh). –Dave | Davey2010Talk 18:27, 23 August 2019 (UTC)
  • Symbol support vote.svg Support but would strongly prefer this to go along with a new flag per 大诺史. I can easily envision filemovers persistently forgetting not to leave redirects when they should, and I'd rather not have to remove their whole filemover right. Storkk (talk) 19:00, 23 August 2019 (UTC)
  • I agree with both 大诺史 and Storkk above that it should be a new flag, so Symbol support vote.svg Support this, but as a new flag, possibly for people with a couple of years experience as a file mover with plenty of precedent to require this. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:34, 26 August 2019 (UTC)
  • Symbol strong support vote.svg Strong support: i don't agree with new flag thing but allowing file movers to suppress redirect will be very useful. -- CptViraj (📧) 18:05, 27 August 2019 (UTC)
  • Symbol support vote.svg Support, if someone is trusted with the file mover bit, this should be part and parcel of it. BD2412 T 04:29, 28 August 2019 (UTC)
  • Pictogram voting comment.svg Note The Ajax moving script will not allow the suppression of redirects if a file is in use. There are ways around this restriction but that fact, I believe, is not well known and in any case the suppression of redirects of an in use file should simply not be done. The creation of redlinks by the purposeful suppression of redirects of an in use file would be considered abuse of the right and grounds for removal in my mind. Just thought I would put that out there. --Majora (talk) 21:29, 28 August 2019 (UTC)
@Majora: The guidance at Commons:File renaming#Redirects will surely need to be updated. Happy to help along with whomever wants to sort that bit out. GMGtalk 22:04, 28 August 2019 (UTC)
In use only concerns Wikimedia projects. It doesn't know anything about hotlinks and external references. This needs some script policy about it. See also Commons:File_redirects#Redirects_left_after_a_file_renaming --Zhuyifei1999 (talk) 16:39, 30 August 2019 (UTC)
  • Symbol support vote.svg Support Masum Reza📞 12:54, 10 September 2019 (UTC)
  • Symbol oppose vote.svg Oppose Deleting or suppressing redirects is a very disruptive practice in most cases and there's no need to make it simpler. In the very rare cases where it's appropriate, an admin can take care of it. See also m:Don't delete redirects. Nemo 20:33, 12 September 2019 (UTC)
  • BA candidate.svg Weak oppose I have seen filemovers wanting to get rid of redirects for the wrong reasons. What comes to mind are the misspelled "Caribean" redirects. I'm also not entirely convinced that file movers need to suppress redirects so frequently that admins can't handle it. Perhaps if I can be convinced this is needed more often and potential damage from the removal of redirects that didn't need removal can be kept under control somehow.. Until then, weak oppose. - Alexis Jazz ping plz 20:53, 12 September 2019 (UTC)

Alternative proposal: bot to handle round robin moves[edit]

A bot could be created to handle the round robin moves. The bot could be set to only respond to requests by specific users or user groups. It should not allow for nonsysop users to perform moves on heavily used or protected images. MorganKevinJ(talk) 12:51, 24 September 2019 (UTC)

@Morgankevinj: I see no problem with that. Maybe CommonsDelinker could be extended/adjusted for this purpose. - Alexis Jazz ping plz 14:53, 28 September 2019 (UTC)

Category titles with scripts other than Latin[edit]

FYI, someone wants to add an exception to our categories policy, enabling the use of Chinese characters in certain category names. --HyperGaruda (talk) 09:11, 25 August 2019 (UTC)

I still think that we should utilise Wikidata to have a bot flood-create category redirects using a new template (Exampli gratia "{{Redirect-de}}", "{{Redirect-fr}}", "{{Redirect-zh-tw}}", "{{Redirect-es}}", "{{Redirect-ar}}", Etc.) that will automatically display the redirected text as the category title for users who have set their standard language as something other than English and allow for the search engine to look for these alternative names and the MediaWiki Upload Wizard interface should utilise redirect categories in the same way HotCat does now during the submission form.
This would be the best outcome for non-Anglophones. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:38, 26 August 2019 (UTC)
I think the site could allow non-latin words in such instance. Just wait for one day the interface allow local language display and someone adds an English translation.--維基小霸王 (talk) 01:08, 2 September 2019 (UTC)

To summarize, directly using Chinese would be the most simple and easy to understand way to categorise book scan files. It has the following advantages:

  1. Easier for Chinese users to obtain. Books are only useful if you can understand them. Chinese users will only search in Chinese for books, not in Pinyin. Categorise books in Chinese will get the files noticed by users from a search engine and maximize their visibility.
  2. Using original language will make other language users easier to translate the titles. For example, if you use Google to translate the Chinese title 中國新海軍插圖, you can get the correct translation. [1] But if you translate its pinyin, you can not. [2] (Since the categories themselves will be categorised as such in English, English language users will understand what they are anyway. If a user can't type Chinese and want to refer to a Chinese language category, the user can copy and paste the Chinese title.)
  3. Wikimedia Commons is an international project. While using the widely-used English language in general categories could allow International cooperations, allowing non-latin in some instance like books scans meets its property of internationalization.
  4. Book scan files mainly serve Wikisource. The multilanguage Oldwikisource: use titles for original text in the original language. Also using titles in original language shows consistency across Wikimedia projects.
  5. The easiest way for mass uploaders to create categories. The alternative is to translate the titles to English or Pinyin. The former is an art itself and needs research in each case. The latter is also difficult because many Chinese characters have more than one pronunciation. If dividing pinyin by words, it will require additional manual work. Such useless labour should better be skipped. --維基小霸王 (talk) 01:46, 2 September 2019 (UTC)
I am talking about modifying the policy. And your response is accusing modifying a existing policy is a violation of the policy? --維基小霸王 (talk) 04:35, 2 September 2019 (UTC)
In general, putting in translated descriptions in the category text area should end up in search just as much as the category name. That is generally where translations go, and would be the source for further translations. You can only have one category, as you can't have multiple translated category names and have media show up in the same category page, which is why we have the English-only rule. If someone needs to upload an English translation of that book, what category name should they use? Or Arabic? The filenames themselves can contain the Chinese name, of course, which would also show up in search, usually in preference to the category. Is there a reason why books aren't uploaded in PDF or .djvu format for Chinese, as a base for Wikisource? Those would have the original title. You can put the images in a Chinese-named gallery if desired as well. I'm not sure I understand a concern here which hasn't been brought up before. I guess having a transliterated title is often not that much more understandable than having the title in the source script, and makes it worse for native speakers without adding much for English. But another problem with categories is if there is a need to subcategorize -- managing that gets more difficult if everyone just uses their own scripts. Or creating related categories, like "Characters in <book>" I think your points 1 through 4 are answered by putting in the original title in Chinese in the text area of a category, which would be expected anyways. (Wikisource native titles are in the main article area I think, like gallery names here, not categories.) Not sure that point 5 is worth changing the policy, as it would apply to all languages of course and then why only book names and not people names or movie names or ship names etc. I may not have an issue with creating a temporary category name in Chinese for upload, then redirecting it to a transliterated category name such that the rest of the work is done by bot, to save some busy work on each file, if that helps any. If books are in .pdf or .djvu format, often only one upload is needed per book -- it would be relatively rare I would have thought to need a category just for that book. Carl Lindberg (talk) 15:44, 6 September 2019 (UTC)
  • Symbol support vote.svg Support Though logically, it is not an exception as the policy already states "Category names should generally be in English, excepting some of proper names, biological taxa and terms which don't have an exact English equivalent." There is nothing there that stops the use of non-English and non-Latin character sets where this makes more sense than bending over backwards to transliterate into pseudo English. As reminder, the tendency to stick to "English" for categories was a Jimmy Wales championed thing from over a decade ago. It's very Americano-centric, and 2019/2020 might be a good time to put together an example case book and have a RfC about making this a better policy and help reduce the classic historical colonial legacy that exists in our infrastructure and recognize that American English does not need to remain our communication default for infrastructure and fundamental structure like categories. -- (talk) 17:15, 6 September 2019 (UTC)
  • Symbol oppose vote.svg Oppose - Commons:Language policy does not mention anything explicitly about the usage of scripture or writing systems. Only the usage of English is a subject, which ofcourse uses the alphabet. In my opinion this policy could use an update. But the implementation of this policy (and other similar policies) is also one of the real issues. For the sake of convenience and mass production, the policy is often poorly followed. I raised the issue before, but I was completely disregarded. For example: If a file title should be descriptive of it's content and in English or at least in Alphabet script, why then allow file titles that only contain the archival coding of a donating institution? I am literally talking about hundreds of thousands or even millions of files by now. Entire libraries are being uploaded without a descriptive title but also without any proper description. Often the description is no more than just the general subject of the file or even just a repetition of the archival coding. Additionally the box for "author" is being abused to advertise the name of the employee or volunteer who scanned or made a 1:1 (PD) photo the work, in stead of the real author, being for example the painter of a painting. Also they'll only create categories for their institutions, but refuse to help categorize files in the existing Commons categories. Many institutions are using Wikimedia Commons as a cheap storage space, while implementing their self promotion within the process. And the most culpable, I think, is the collaboration that Commons editors provide. They often even defend this way of working. Under the motto that this is how Commons acquires new media. --- Now I'll get back to the specific subject at hand. If you combine the demand for allowing all scripts with the other issues I've been describing, you will end up in the biblical Babylon and Commons Wikimedia will end up in utter chaos while being useless for the end users of the files. I have been noticing that many or even most people who write file names in non alphabet script, also do not add any description in any alphabet script. Combined with names of categories in non alphabet script, how are people who can not understand the text going find out what the content of file is? And how to moderate for abusive language or content, when we mostly depend on community driven moderation? To conclude, I have the opinion, being a non native English speaking person, that the Commons policy should not allow the usage of non alphabet text in file names and categories, while adding an English description should be mandatory when adding a non alphabet script text as a primary description. After all, don't we intend to be a global community of like minded spirits? A community that aims to share content and knowledge for all to use freely? Then accessibility should be at the foundation of all policies. Please speak out if you support me on this. --oSeveno (User talk) 11:26, 8 September 2019 (UTC)
    @oSeveno: I support you on this.   — Jeff G. please ping or talk to me 13:20, 8 September 2019 (UTC)
    Only using alphabet script is the contradictory of being global.--維基小霸王 (talk) 04:59, 11 September 2019 (UTC)
    @OSeveno: I respectfully disagree with you. Google Translate is a useful tool, you know. When you say "Alphabet script", do you mean that only Latin, Cyrillic, Greek, Armenian, and Georgian scripts are allowed, but all Abjad writing systems (Arabic and Hebrew scripts), Abugida writing systems (Indic and Ethiopic scripts), and CJK characters are forbidden? Please take a look at w:Template:Writing systems worldwide. 4nn1l2 (talk) 09:00, 11 October 2019 (UTC)
  • I respect your point of view as well. It is my believe though that Wikimedia Commons should operate in (specifically) Latin Alphabet. Not because it's the "dominating" Western-centralist script, but because I believe we as a community should be above chauvinistic and nationalistic sentiments. And because Wikimedia, including the software behind it, was build up from the English language. And because by far most users and editors of Wikimedia read and write the English language as a native or second language (or third language et cetera). We need a shared working language, or Commons Wikimedia will become increasingly chaotic in usage. This should be the place were like-minded people should work together for a common good. If we can't agree on this, we will become increasingly divided among each other, where we only communicate with people that share the same language or script. So, if current policies allow the use of different scripts, then yes, I am in favor of restricting that for file upload descriptions, categories and titles, whilst allowing second or third language (and script) translations of the descriptions in addition. I myself, being Dutch, am a non native English speaker, and I accept the dominant role of the English language for achieving our common goals. Please consider approaching this subject from this point of view. --oSeveno (User talk) 09:46, 11 October 2019 (UTC)
  • I'm not sure why we need this proposal. Scripts other than Latin are already allowed, where non-English words are allowed (such as for proper names). Nemo 20:32, 12 September 2019 (UTC)
    Got it.--維基小霸王 (talk) 07:05, 16 September 2019 (UTC)
Symbol oppose vote.svg Oppose. Transliteration is better than the original alphabet. I always have a headache when I see arabic/hebrew/brahmic scripts. I can imagine what other people feel when they see hanzi/kanji/kanas/hanguls.--Roy17 (talk) 15:51, 19 September 2019 (UTC)

Proposal to replace Template:Indefblocked-global with Template:Indefblocked-global-WPstyle[edit]

As the creator of Template:Indefblocked-global-WPstyle, I vow to replace the legacy {{Indefblocked-global}} with {{Indefblocked-global-WPstyle}}. After the legacy template gets replaced, the WPstyle template will be renamed to "Template:Indefblocked-global". Calvinkulit (talk) 14:07, 6 September 2019 (UTC)

  • Pictogram-voting-question.svg Question: Did you copy this new template from enwiki? -- CptViraj (📧) 04:47, 8 September 2019 (UTC)
  • Pictogram-voting-question.svg Question: Could you add some explanation at the template page on what the template is about? I understand it, but not everyone will. Also, the template could contain a link to a page explaining what the block means or how to appeal. For general accessibility reasons. Then I'll support your proposal. Kind regards, --oSeveno (User talk) 11:32, 8 September 2019 (UTC)
  • @CptViraj, OSeveno: 1. I copied it from enwiki. 2. It's the same as the legacy template, only that it has more flexibility. Calvinkulit (talk) 06:15, 10 September 2019 (UTC)
@Calvinkulit: The lack of extra information is one of the reasons that Commons/Wikipedia has such a steep learning curve for newcomers. I'd like us all to help do something about that. It only requires a little extra effort. --oSeveno (User talk) 10:30, 10 September 2019 (UTC)
@OSeveno: Fixed, check it out. Calvinkulit (talk) 11:17, 10 September 2019 (UTC)
Symbol support vote.svg Support Thanks! It's really well done. I now fully support your proposal. Regards, --oSeveno (User talk) 11:49, 10 September 2019 (UTC)

@Masumrezarock100: I tried to make a French translation, but it failed. Calvinkulit (talk) 01:51, 11 September 2019 (UTC)

@Calvinkulit: To translate a page, first it needs to be marked for translation by a translation admin. Masum Reza📞 04:20, 11 September 2019 (UTC)
@Calvinkulit: marked for translation. MorganKevinJ(talk) 04:55, 11 September 2019 (UTC)
@Calvinkulit: I have made a translation into the Dutch (Netherlands) language. --oSeveno (User talk) 11:38, 12 September 2019 (UTC)
@Morgankevinj:I think there's a problem with the <translate> tag, see User:Achim55555's userpage for example. Ahmadtalk 09:16, 21 September 2019 (UTC)
fixed MorganKevinJ(talk) 15:52, 24 September 2019 (UTC)
I added bn (Bengali) translations. Masum Reza📞 15:20, 16 September 2019 (UTC)

More Of This ⬅️, Less Of That ➡️[edit]

I'm curious if there is a section on Wikimedia Commons or Wikipedia where users can specify images that they need more of or a specific image that is needed to fill an article?

For instance, it would be great to have a picture of an Icosahedrite (I'm a geologist and recently read this article) to go on this page:

Not sure if that exists somewhere but it would be helpful to find photos that need to be taken to fill in gaps on Wikimedia/Wikipedia.--Tenace10 (talk) 14:50, 9 September 2019 (UTC)

@Tenace10:, technically there is "Commons:Picture requests/Requests", but in reality these requests are rarely answered. Personally I'd rather see some sort of category which uses either local Wikimedia websites or Wikidata that creates a list of topics needing images and that this category can be sub-divided into multiple subjects which people can patrol. It might be wise to devise a better system, I do know that the English language Wikipedia has a "Picture needed" template, but I am not aware of any active photographers trying to tackle these huge backlogs. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:19, 10 September 2019 (UTC)
Thanks Donald, this is really helpful. I'd imagine there is a constant and large backlog of images that would be great to have on the platform. But this gives me a good place to start looking!--Tenace10 (talk) 15:17, 11 September 2019 (UTC)
@Tenace10: The template is at en:Template:Photo requested; I added it to the Icosahedrite article's talk page in this edit Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:51, 20 September 2019 (UTC)

Make the Confirmed right automatically revoked after the account is 4 days old[edit]

The Autoconfirmed right will get applied after the account is 4 days old on this wiki, so Confirmed would be redundant. With this change, there will be a new filter that automatically revokes the Confirmed right if the user is 4 (or more) days old. Calvinkulit (talk) 02:36, 12 September 2019 (UTC)

Symbol support vote.svg Support but I am not sure filters can do such things. Masum Reza📞 04:49, 12 September 2019 (UTC)
Pictogram voting comment.svg Comment This only concerns 0 users, they can easily be dealt with by hand. - Alexis Jazz ping plz 10:41, 12 September 2019 (UTC)
@Alexis Jazz: So a request to a moderator to have this taken care of should be sufficient? --oSeveno (User talk) 11:42, 12 September 2019 (UTC)
@OSeveno: I think so. - Alexis Jazz ping plz 14:17, 12 September 2019 (UTC)
@Alexis Jazz: Already done at COM:RFR. Calvinkulit (talk) 15:52, 12 September 2019 (UTC)
Pictogram-voting-question.svg Question Why do users with confirmed rights get the autoconfirmend rights? Would it not be possible to say that users with confirmed rights do not get the autoconfirmend rights and stay with that confirmed rights till they get other rights? --GPSLeo (talk) 11:46, 12 September 2019 (UTC)
@GPSLeo: Before, when a confirmed user gets autoconfirmed, the confirmed right would be revoked. And that practice is still here today. Also, the autoconfirmed right is permanent compared to the confirmed right as special rights like the Confirmed right get revoked when the person gets blocked from editing. But, revoking the Confirmed rank from a person that is already autoconfirmed is like trying to battle with your own shadow. Calvinkulit (talk) 11:57, 12 September 2019 (UTC)
Pictogram voting comment.svg Comment Made a task for it: Automatically remove confirmed user right when eligible for autoconfirmed. This isn't specific to Commons. - Alexis Jazz ping plz 16:24, 12 September 2019 (UTC)
@Alexis Jazz: Thank you. Calvinkulit (talk) 02:49, 13 September 2019 (UTC)

Closed per User:Masumrezarock100 MorganKevinJ(talk) 18:42, 2 October 2019 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Enable Flickr import (upload_by_url) for all users[edit]

Currently, users who are not autopatrolled either use Flickr2Commons or they cause problems when trying to upload by hand. Copy-pasting the wrong source link, accidentally upload thumbnails, directly uploading crops without the originals, things like that. License reviewers are left to clean up the mess. UploadWizard can take care of many of these issues as it automatically inserts the correct information. Similar previous proposals like "Allow all users to use Upload Wizard's flickr option" didn't succeed because at the time there was no server side license check for these uploads. This has been fixed nowadays.

To ease the concern of mass Flickr uploads, the proposal limits users to 4 (four) images each run for Flickr imports. This should be enough to allow a new user to upload a few images they need for an article, which is the primary purpose of this proposal. The maximum number of Flickr imports will be disconnected from the maximum number of files that can be uploaded with UploadWizard. (this is technically feasible) This proposal does not affect anyone who has the autopatrolled flag. Users without autopatrolled flag will be granted the upload_by_url right limited to whitelisted domains (this is required to enable Flickr import) and be given a limit of 4 images each run for Flickr imports. - Alexis Jazz ping plz 16:36, 16 September 2019 (UTC)

Enable Flickr import (upload_by_url) for all users (four images each run): votes[edit]

  • Symbol support vote.svg Support as proposer. - Alexis Jazz ping plz 16:36, 16 September 2019 (UTC)
  • Symbol support vote.svg Support, the democratisation of Wikimedia Commons is here! We should place functionality front and centre and not hide it behind user rights. Someone who mostly edits Wikipedia and finds an amazing photoshoot in a museum on Flickr released with a compatible license who doesn't know that Flickr2Commons exists and doesn't look at Wikimedia Commons beyond the MediaWiki Upload Wizard and the images they published will never upload it. We should work to maximise content creation and the MWUW already knows how to prevent Flickr uploads with incompatible licenses. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:33, 10 June 2019 (UTC)
  • For Flickr uploads, definitely Symbol support vote.svg Support. But upload by url user right can be used import media from sites other than Flickr using Special:Upload. Unless the import URL gets automatically included in the upload summary, or in the file summary, Symbol oppose vote.svg Oppose. Because some inexperienced users claim own work even when they copy a file from other sites and then upload here. It will be very helpful to detect the original source. Masum Reza📞 17:34, 16 September 2019 (UTC)
  • Symbol oppose vote.svg Oppose - I would support if the system could somehow identify what licences are used and what are accepted (basically the same as Flickr2Commons which rejects files that don't have the accepted licence here), I certainly agree in that things should be made easier for people absolutely agree with that but I feel newbs could easily upload any given file from URL regardless of licence ..... which would then mean it's down to us to tag and delete. –Davey2010Talk 18:41, 16 September 2019 (UTC)
  • Symbol support vote.svg Support - My bad I assumed the Flickr upload by URL option allowed all files willy nilly ....I didn't realise a restriction to upload non-CC content was placed on it, I now fully support this proposal. –Davey2010Talk 21:29, 16 September 2019 (UTC)
  • Symbol support vote.svg Support Uploading a picture from flickr manually isn't easy for everyone (especially for new users). I assume that most users with autopatrol right already know how to manually upload a picture from Flickr, so the tool only makes it easier for them. But when talking about new users willing to upload a picture from Flickr, it isn't just about making their job easier. In addition to what Alexis Jazz mentioned above, I think some new users who aren't familiar with licencing policy might mistakenly upload non-free files from Flickr. About uploading non-free files from url, I think it isn't much of a problem since new users don't use Special:Upload very often; they are much more likely to use upload wizard or perform a cross-wiki upload from their home wiki. Ahmadtalk 18:29, 18 September 2019 (UTC)
Symbol support vote.svg Support sounds like a good idea. gonna save lots of time fixing all the problems that arise from nonstandard transfers.--Roy17 (talk) 15:51, 19 September 2019 (UTC)
  • Symbol support vote.svg Support Since the feature is whitelisted (and not many people use Flickr anymore anyway) it seems like it shouldn't be a huge risk. If copyvios become a problem we can always go back to having it restricted. Kaldari (talk) 18:36, 20 September 2019 (UTC)
  • Symbol support vote.svg Support (Talk/留言/토론/Discussion) 07:38, 6 October 2019 (UTC)
  • Symbol oppose vote.svg Oppose It is actually easy to upload flickr images which seem free enough, but are not. I unintentionally attempted to upload one of those images to commons, but fortunately that image is not on commons anymore. Sure, there are safeguards for flickr uploads, but they really do not go far enough.--Snaevar (talk) 23:23, 8 October 2019 (UTC)

Enable Flickr import (upload_by_url) for all users: discussion[edit]

Discuss details for this proposal here.

  • Donald Trung's vote copied from incubator by request. - Alexis Jazz ping plz 16:36, 16 September 2019 (UTC)
  • @Masumrezarock100: see phab:T20112. But upload_by_url doesn't allow anything you can't accomplish by downloading a file and uploading it here. New users are unlikely to use Special:Upload and as the feature is limited to a whitelist anyway, the potential for abuse is quite tiny. - Alexis Jazz ping plz 18:30, 16 September 2019 (UTC)
    Yes but let's assume that a newbie wants to overwrite another file. How they would do? Using Special:Upload, because UploadWizard currently doesn't support overwriting files. Now we know that Flickr hosts non-free(copyrighted) and free files. So if that newbie intentionally or unintentionally copies files direct download URL to the URL field, Special:Upload would accept the file because is whitelisted! I understand what you're saying but there is this slight chance of misuse, that's what bugging me. The proposal below should solve the problem, and I suppose UploadWizard can be configured in a way that anyone can use the Flickr upload feature. Until then my vote is Symbol neutral vote.svg Neutral, leaning towards GA candidate.svg Weak support. Masum Reza📞 14:41, 7 October 2019 (UTC)
@Masumrezarock100: Thank you, and yes, that's absolutely right, though overwriting files that are not yours is restricted to autoconfirmed users. Granted, those are still newbies. But also, the scenario you are describing is a direct violation of COM:OVERWRITE and is typically met with revision deletion. I've seen it happen sometimes. Not very frequent, but it happens. Copying the right link from Flickr is not entirely straightforward though (you can't right-click the image), so while there could be some freak occurences, I don't see this becoming a substantial thing. If we saw a large number of newbies performing bad overwrites (regardless of method), it would be more sane to increase the requirements for autoconfirmed. - Alexis Jazz ping plz 15:02, 7 October 2019 (UTC)
  • @Davey2010: If I try to upload (all rights reserved) with UploadWizard, I get the error "The file is under the following license on the source site "Flickr": All Rights Reserved. Unfortunately, this wiki does not allow that license.", isn't that what you mean? And to upload from other whitelisted domains one would have to use Special:Upload, the existence of which newbs aren't even aware of. Newbs who upload copyvio download their images from any website (not restricted by the whitelist) and upload them here with UploadWizard or cross-wiki upload. Upload_by_url doesn't assist them with that. - Alexis Jazz ping plz 19:15, 16 September 2019 (UTC)
  • Ah thank you Alexis Jazz - I just assumed you could upload via a URL and the system never picked it up, Also I didn't even realise Flickr upload was only available to us, Changed my vote accordingly :), Thanks, –Davey2010Talk
  • @Alexis Jazz: Right now, users with upload_by_url can import up to 50 images at once via UploadWizard. Users with upload_by_url and mass_upload can import up to 500 images at once. I'm assuming your restriction to 4 images at a time would not affect users with mass_upload. Is that correct? And this would only be in relation to Flickr importing via UploadWizard. Correct? Kaldari (talk) 18:11, 20 September 2019 (UTC)
@Kaldari: All correct. As the proposal also states: "This proposal does not affect anyone who has the autopatrolled flag.", and only users with the autopatrolled flag have mass-upload. By the way, users with upload_by_url but without mass_upload currently don't exist on Commons. In theory a user could have the GWToolset right, but all the users on Commons who do are also autopatrolled. The restriction of 4 images each run only applies to Flickr imports with UploadWizard. Non-Flickr uploads with UploadWizard are not affected and any other upload methods are not affected either. - Alexis Jazz ping plz 18:29, 20 September 2019 (UTC)
Thanks for the clarification. I've added my vote of support. Kaldari (talk) 18:36, 20 September 2019 (UTC)
Thank you. To be even more clear for anyone else who might still be confused: the restriction of 4 images each run will only apply to users who currently are unable to use UploadWizard Flickr imports at all. This proposal will not limit anything users currently have. - Alexis Jazz ping plz 18:42, 20 September 2019 (UTC)
  • @Snaevar: Which file was that? You don't seem to have any recently deleted files. Perhaps filters/checks can be improved. Things like people not knowing about FoP and the like equally apply to own work uploads. That's not Flickr-specific. - Alexis Jazz ping plz 23:29, 8 October 2019 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Restrict move permission for root userpages[edit]

Moving userpages to another user should make for normal users no sense, instead it opens doors for confusing, faults and misusing.
Solution: setting the move-rootuserpages right as minimum to the autopatrol right. E.g.: User:Asik_Mahmud_Hassan_(ARMBD). -- User: Perhelion 17:01, 16 September 2019 (UTC)

  • Symbol support vote.svg Support Assuming this only applies to the userpage itself (which I assume is what "rootuserpage" refers to) and subpages (like User:Example/sandbox) can still be moved. - Alexis Jazz ping plz 17:16, 16 September 2019 (UTC)
  • Question What if a global renamer doesn't have autopatrolled permission on Commons? Do you plan to make an exception for them? Masum Reza📞 17:36, 16 September 2019 (UTC)
Good hint, of course. We could also made instead of autopatrol a edit-limit of 100? (of course with global renamer exemption). -- User: Perhelion 17:56, 16 September 2019 (UTC)
Good to know. I fully Symbol support vote.svg Support this proposal.
— Preceding unsigned comment added by Masumrezarock100 (talk • contribs)
@Perhelion: There are 36 stewards and 68 global renamers. I'm guessing most if not all could be granted autopatrol anyway? Only those who are active on Commons outside of renaming and require patrolling would be an issue. Alternatively I guess you could add move-rootuserpages to another user group (file mover maybe, or an entirely new group) and give stewards and global renamers that. - Alexis Jazz ping plz 18:17, 16 September 2019 (UTC)
Global renamers and stewards without autopatrol. (22 total atm) - Alexis Jazz ping plz 02:28, 17 September 2019 (UTC)
@Alexis Jazz: According to meta, global renamer's edits when renaming is autopatrolled. (Talk/留言/토론/Discussion) 02:56, 17 September 2019 (UTC)
@大诺史: Where does it say that? Anyway, it's stranger than that. Deepfriedokra is blocked here, but that doesn't stop Deepfriedokra from renaming accounts here. - Alexis Jazz ping plz 03:10, 17 September 2019 (UTC)
Correct. Centralauth would probably freak out if one of the various account pages couldn't be moved during the process. So the global renamer extension overrides local blocks. That way if something like a self requested local block is in effect renames can proceed as normal. --Majora (talk) 03:20, 17 September 2019 (UTC)
@Alexis Jazz: It states "Have one's own edits automatically marked as patrolled (autopatrol)" so I assume that the rename is included in the process. (Talk/留言/토론/Discussion) 03:25, 17 September 2019 (UTC)
Global renamer is a local group on meta. "Global" is a misnomer. Their local edits to meta are autopatrolled. I don't believe that right extends globally. --Majora (talk) 03:28, 17 September 2019 (UTC)
True. It's a local permission on Meta. – Ammarpad (talk) 06:39, 17 September 2019 (UTC)
Note that Stewards get autopatrol from the global group (which is truly global unlike "global" renamer). — regards, Revi 00:48, 4 October 2019 (UTC)
  • Global renamers (i.e including stewards) do not have nor use move-rootuserpages permission when renaming users. That ability comes from the extension which already provides many other things like bypassing local blocks, abuse filters as well as non-existent renamer's local account on a particular wiki. – Ammarpad (talk) 06:39, 17 September 2019 (UTC)
    Thanks for the hint, and confirmed phab:T212082, so all this filter technique talk here doesn't matter. I've already created prematurely (inactive) filter 220. -- User: Perhelion 08:18, 17 September 2019 (UTC)
    @Majora: "Global" is a misnomer: That's right phab:T85023. -- User: Perhelion 08:30, 17 September 2019 (UTC)
    So all this filter technique talk here doesn't matter. If the (right) filter is enabled only Global renamers (and users explicitly excluded) can do the action. But your inactive filter was incomplete and could be optimized. – Ammarpad (talk) 23:21, 17 September 2019 (UTC)
  • Symbol oppose vote.svg Oppose This is a confusing and bureaucratic change based on hypotheticals. Changes of this type, which increase the bureaucratic burden of administering or understanding Commons processes, should only be passed when there is a driving need based on actual cases of disruption or abuse, not theory. -- (talk) 08:59, 17 September 2019 (UTC)
What? The contrary is the case, I've linked an actual example. Why this should not simplify the admin activity? There are already 219 filter on Commons and e.g. on the EnWP over 800, so your arguments seems rather hypotheticals. This filter is already active in some Wikis for this reasons. -- User: Perhelion 09:28, 17 September 2019 (UTC)
The link you gave was to a user page without any explanation. The case was a user apparently thinking that moving their user page would somehow rename their account, no harm was done, and the response can be to advise the user on how to request a name change. So far, there have been zero examples of meaningful cases of disruption or abuse that need to make the process of renaming pages on Commons more complex. Putting constraints on page moves for all users does not automatically "simplify the admin activity" as there has been no attempt to assess how much admin burden not restricting page moves creates compares to the burden on all users of making page moves more restricted and therefore increasing this project's bureaucracy.
This proposal exists, but a positive and verifiable case for making the change has not been made. -- (talk) 10:03, 17 September 2019 (UTC)
@: Can you give any example, anything at all, where it would be valid for a user to move a user page? (other than undoing faulty moves by inexperienced users) - Alexis Jazz ping plz 17:04, 17 September 2019 (UTC)
Drafts. -- (talk) 19:01, 17 September 2019 (UTC)
@: Drafts? On Commons? On a user page, instead of a user subpage? - Alexis Jazz ping plz 19:03, 17 September 2019 (UTC)
Not sure why you are painting this as weird. I have seen admins draft policies and funded collegial project pages drafted in user space, including role accounts. The is no evidence that more restrictions on doing this on "root" pages would reduce this project's maintenance or administrative burden, quite the opposite.
Come on people, this is Commons, called the Wild West by other other projects due to our lack of rules. Do you really want to keep on adding rules and bureaucracy to Commons until us four legs have all the same problems as the two legs? -- (talk) 20:10, 17 September 2019 (UTC)
I don't see why we can not add it as a precautionary measure. Just because no one did doesn't mean no one ever will. There is a say "Precaution is better than cure." Masum Reza📞 20:20, 17 September 2019 (UTC)
This is the same rationale that is used in every case of power hoarding for the sake of it. -- (talk) 20:55, 17 September 2019 (UTC)
User space is not the same thing as the user root page. - Alexis Jazz ping plz 21:25, 17 September 2019 (UTC)

@: The link you gave was to a user page without any explanation. It was not a userpage. It's a demonstration of the actual problem (has to be deleted after this discussion, I guess). There's no user "Asik Mahmud Hassan (ARMBD) (talk · contribs) on Commons or even globally. That (user)page was created by Asikmahmud338 (talk · contribs) who incorrectly thought they were renaming themselves if they move the userpage. – Ammarpad (talk) 22:59, 17 September 2019 (UTC)

@Examples: I made a very concrete DB search query of the last 30 days only, which hits 6 moves, which all are crap and not fixed by anyone. -- User: Perhelion 20:37, 17 September 2019 (UTC)
That is a useful report that appears to show that the systemic change is very much not needed. 2 of the 6 are the case already raised, and the institutional move looks like it may be right. The fact is that "not fixed by anyone" is in truth "nobody cares and it does not affect anyone". The proposed bureaucracy is neither urgent, nor does it fix anything that was causing anyone a headache. -- (talk) 20:51, 17 September 2019 (UTC)
In fact it are much more (e.g User:Jubair Bin Iqbal from yesterday). More examples 300 potentially hits (forked query, not all checked).
@"nobody cares and it does not affect anyone" I think your arguments are not meant seriously. -- User: Perhelion 21:19, 17 September 2019 (UTC)
Based on your query, that's still 6 cases in 30 days as it already included Jubair Bin Iqbal, and I have no idea why you think any of those 6 cases are a cogent argument to make this system wide change for all users. Some of these moves may be mistaken, but they are not damaging the project as far as I can see and have not affected anyone else, or at least you have not linked to cases where anyone cared enough to complain about it. BTW, the institutional page move, Institution:Fravahar Choir, is exactly the sort of thing you might do when drafting a template, so that fits with the 'drafts' question above. Hardly "all are crap". -- (talk) 21:48, 17 September 2019 (UTC)
@"already included Jubair Bin Iqbal" not really, I refreshed the query with raised editcount, so the hit count is raised.
@Hardly "all are crap": Institution:Fravahar Choir is neither an institution in his Commons intention nor a template nor used. Maybe "crap" was too hardly expressed, but using the root userpage as 'drafts' is is certainly not the purpose of it, not to mention to leave redirect to this (and I've also never seen this before). The discussion becomes unnecessarily bloated and too pointless for me. -- User: Perhelion 23:11, 17 September 2019 (UTC)
That's still 6 cases in 30 days. At worst there are 300 pages that might be examined as relevant but may be double counting some cases in 5 years, based on your own report. This is a trivial number in comparison to other backlogs and issues that cause real measurable disruption to the project. None of the evidence or cases so far is in any way convincing that time and effort should be spent making a systems change to make special protection and distinctions in user rights for "root" user pages. The principle of sticking to the least bureaucratic systems is one that should be the default for Wikimedia Commons, not one of increasing bureaucracy "as a precaution" for hypothetical issues. -- (talk) 06:27, 18 September 2019 (UTC)
There are proven to be some screwups. On the other hand, I'm not convinced by the actual use case for moving root user pages. For example, if a user were to create a draft on a user root page (did that even ever happen?), by default, when moving that page the checkbox for "Move associated talk page" is enabled by default which is really not desirable. Now, you could maybe create an abuse filter that warns the user that moving a root user page does not accomplish a rename but allows the user to ignore that warning, but still.. Who actually needs this? - Alexis Jazz ping plz 15:43, 18 September 2019 (UTC)
Pictogram-voting-question.svg Question I'm confused by the talk of abuse filters. Isn't this just a matter of flipping some bits in the user group data? – BMacZero (🗩) 06:13, 19 September 2019 (UTC)
The AbuseFilter is another alternative being considered and is more flexible than the configuration change. – Ammarpad (talk) 13:10, 19 September 2019 (UTC)
Indeed, we could also use a local JavaScript hack to hide only the Move-link at the relevant root-userpages (as the relevant user variables are stored on each page, without need of additional Api request). -- User: Perhelion 21:08, 19 September 2019 (UTC)
Okay, I see. I'd Symbol support vote.svg Support preferably the config change but alternatively the Abuse Filter. This seems to occur primarily when users think they can use it to change their username or display name, which they can't, so cluing them in to that before they do it is a good thing. I'd Symbol oppose vote.svg Oppose any client-side Javascript for such a low-frequency problem, though. – BMacZero (🗩) 04:01, 20 September 2019 (UTC)
This seems to be an interesting proposal for Mediawiki in general. No one is expected to move their userpages to another root userpage.--Roy17 (talk) 15:51, 19 September 2019 (UTC)
  • It's indeed a minor issue, but I Symbol support vote.svg support this proposal. I moved back several pages where users tried to rename their accounts. A similar case that happened as well (though rarely) is moving a userpage intentionally to a gallery page because an "article" page looks better. That should be prevented, too. --Achim (talk) 16:39, 20 September 2019 (UTC)
  • Symbol support vote.svg Support Root user page moves are only really valid alongside user renames.--Snaevar (talk) 23:20, 8 October 2019 (UTC)

A DR noticeboard for language/country-specific issues[edit]

How about a noticeboard, on which users could transclude controversial DRs that need help from miniority linguistic/national groups? Its structure would be something like

== Arabic (1) ==

== Chinese (1) ==

== Japanese (2) ==


Anyone can list a discussion manually. A bot would remove archived DRs and update the number. This might help decision making in cases that involve minority languages/lesser-known countries' laws.--Roy17 (talk) 16:36, 19 September 2019 (UTC)

Symbol support vote.svg Support I am unsure how effective this will be, but it can't hurt to try. If it doesn't work, no harm done. If it works, awesome. - Alexis Jazz ping plz 18:47, 19 September 2019 (UTC)
  • Symbol support vote.svg Support: Interesting idea. Needs development and maintenance, though. -- Tuválkin 19:21, 19 September 2019 (UTC)
  • Symbol support vote.svg Support: There is indeed a potential need for this. From the technical side (and as a maintain member of the DR script) I've no idea how to solve this, it should be relatively hard to develop (if it should be user friendly). -- User: Perhelion 21:37, 19 September 2019 (UTC)
    No, I said discussions were to be listed manually. Whoever thinks a discussion might merit specific communities' help could add it to the proposed page manually, but not every discussion has to be listed (automatically as you and Jeff G seem to suggest). (So it could include CfD too.) Krdbot removes closed DRs. SteinsplitterBot removes closed CfDs. We'll just need an automatic counter that counts how many lines starting with { exist under a section. Actually, the page could be created right now and the bots could be configured to check the page. Only the counter is missing. The counter is helpful to quickly check whether a language has something pending, because if this were implemented, tens of languages are expected on the page.
    This would hopefully be a better venue to seek help rather than visiting the graveyards {{Lang-VP}} or going to the individual wikis.--Roy17 (talk) 22:11, 21 September 2019 (UTC)
    So... about the counter, I know we can simply set it using a bot, but I also think that, with a bit change of plans, we can create it using {{Count on page}}. Now, the thing is that this template doesn't check a page's source, but checks its visible content (basically, what you can actually see in a page is what it counts). So for example, in Special:PermaLink/367876566, it returns 516 occurrences of "File" or "Files" in Commons:Deletion requests/2019/09/20. Now, if a bot is going to set the counter(s), the idea can be just as above, but using this template needs a bit of change in that structure, because this template needs a page to search in it, and we need the counter(s) to be language-specific. So to use this template to set the counter, we'll need a subpage for each language (and we'll just transclude that subpage in the main DR page, it can also help keeping its source clean). Is this idea helpful? Ahmadtalk 18:09, 23 September 2019 (UTC)
    Oh, I found a better template: {{String count}}. This one searches the source of a page, we can simply set it to count occurrences of "Commons:Deletion requests/" in a page; but the subpage problem is still there. You can see an example in Special:PermaLink/367994721, it's just like counting the number of DRs transcluded in a page. Ahmadtalk 14:49, 24 September 2019 (UTC)
    ...Maybe something like {{DR counter box}}; you can see the result in Special:PermaLink/368007075. Please feel free to edit the template! Ahmadtalk 16:32, 24 September 2019 (UTC)
  • Symbol support vote.svg Support, perhaps with cats automatically determined by the encoding of the pagename.   — Jeff G. please ping or talk to me 16:53, 20 September 2019 (UTC)
  • Pictogram voting comment.svg Comment Sounds like a good idea, but maybe it would be better to have separate (sub-) pages for the different languages. That way, you can add the couple of languages you know well enough to your watchlist and won't be bothered by the rest. The single language subpages could still be transcluded to the main page. --El Grafo (talk) 14:06, 24 September 2019 (UTC)
  • Symbol support vote.svg Support but with specific subpage for each language (and we will eventually transclude those subpages in main page). In addition to technical reasons I've mentioned above, what El Grafo mentioned is another benefit it'll cause. Ahmadtalk 18:43, 24 September 2019 (UTC)
  • Symbol support vote.svg Support, I've actually wanted to propose more tools that bring deletion requests more to the attention of more users. In the current system they basically only get seen by a handful of users and often don't get as much community input unless they're massive. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 10:29, 2 October 2019 (UTC)


I suggest the page be titled Discussions by language. Each language would have a subpage Discussions by language/xx using its langcode as in Category:Commons by language. What do you think?--Roy17 (talk) 21:28, 10 October 2019 (UTC)

Make upload comments more informative[edit]

Update: I misinterpreted AKlapper (WMF) when he said agreement was needed as a need for community consensus. Regardless, your input on the task is welcome to help craft the most optimal message.

User created page with UploadWizard

The dreaded message. Often all that's left after a deletion. It doesn't allow us to verify if a deletion was justified. It doesn't allow us to verify a new upload is a re-upload that could be speedied. It tells re-users nothing when they suddenly find the source for the file they were using deleted, which can also easily break the attribution requirement of Creative Commons if the re-user relied on just a link to the file page.

I created a task on Phabricator, but community consensus is required. So the proposal is:

  • Include information like source, author and license in the upload comment when using UploadWizard.
  • For uploads with Special:Upload, the description in the wikitext that's copied to the upload comment may be shortened or moved to increase the odds of the author and source being included. (by default, description comes before author and source, a long description causes author and source to be truncated) The actual wikitext is not affected, only its (truncated) copy in the upload comment.
  • Cross-wiki upload comments are not affected right now because they only allow "own work", but will be changed in similar ways if/when cross-wiki uploads become more flexible.
  • Other upload methods (Video2Commons, Flickr2Commons, other upload tools) are not affected. (the developer of those is responsible for the generated upload comment)

This will be a great step towards more transparency for Commons. - Alexis Jazz ping plz 10:32, 30 September 2019 (UTC)

Make upload comments more informative: votes[edit]

  • Symbol support vote.svg Support - Alexis Jazz ping plz 10:32, 30 September 2019 (UTC)
  • Symbol support vote.svg Support It's not really blocked on community consensus. Creating patches may take some time. -- Masum Reza📞 10:59, 30 September 2019 (UTC)
  • Symbol support vote.svg Support Seems a reasonable improvement with no downsides. -- (talk) 13:20, 30 September 2019 (UTC)
  • Symbol support vote.svg Support, why even have logs if they essentially give no information? There's only so much we can tell from a file name. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 10:32, 2 October 2019 (UTC)
  • Symbol support vote.svg Support --GPSLeo (talk) 10:49, 2 October 2019 (UTC)
  • Symbol support vote.svg Support -- Tuválkin 14:51, 2 October 2019 (UTC)
  • Symbol support vote.svg Support -- CptViraj (📧) 08:47, 6 October 2019 (UTC)
  • Yes plz. User created page with UploadWizard is completely useless.--Roy17 (talk) 21:28, 10 October 2019 (UTC)
  • Symbol support vote.svg Support.--BevinKacon (talk) 09:28, 13 October 2019 (UTC)

Make upload comments more informative: discussion[edit]

It is unclear what is being asked for in this proposal. Could you outline something like a state-machine for how comments would be generated and therefore make it clearer what would be improved and how? Thanks -- (talk) 10:48, 30 September 2019 (UTC)

@: See my suggestion on phab:T234192#5533622. - Alexis Jazz ping plz 11:08, 30 September 2019 (UTC)
Looks simples, maybe it can include a bit more intelligent harvesting? No firm feelings about this because I'm unsure how easy it would be to harvest other useful data like whether the source URL is actually readable, or stuff from the EXIF if absent from the Commons info template. -- (talk) 11:55, 30 September 2019 (UTC)
@: I don't know about checking the source url (might be vulnerable to abuse?), but I'd guess that getting information from the EXIF would be possible. But I'm not a programmer, so I don't quite know how to realize that. I'm sure there are others here who do know. - Alexis Jazz ping plz 13:17, 30 September 2019 (UTC)

DjVu is dead. We should deprecate it for new uploads.[edit]

I withdraw the proposal, as it seems to have been premature. More discussion on improving MediaWiki's PDF support is welcome however. Kaldari (talk) 05:17, 9 October 2019 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The DjVu file format has been dying a slow death for many years. The reference implementation for DjVu hasn't been updated since 2015; WinDjView also hasn't been updated since 2015. DjView for Mac hasn't been updated since 2013; The Java DjVu Viewer hasn't been updated since 2005; Internet Archive dropped support for DjVu in 2016 (for new uploads); the main DjVu community website hasn't had a news update since 2013; PlanetDjVu, the main discussion forum for DjVu, was closed in 2014. Wikimedia Commons is the only place left on the internet that still uses it. It's only a matter of time before the basic DjVu software stops working with current operating systems. (It already has problems with newer versions of MacOS.) We should deprecate accepting DjVu files for new uploads, as those files will eventually become unusable and all need to be converted to PDFs (or some other format). Kaldari (talk) 18:23, 7 October 2019 (UTC)

  • Symbol support vote.svg Support Converting to PDF sounds like a good plan to me. Masum Reza📞 18:40, 7 October 2019 (UTC)
    • Just to clarify, this proposal is only about deprecating the acceptance of new DjVu files. What to do with the existing DjVu files will have to be dealt with separately. Kaldari (talk) 18:53, 7 October 2019 (UTC)
      • Sorry for not being clear. I support this proposal about deprecating the acceptance of djvu files. And also converting existing files to PDF sounds like a good plan to me. Masum Reza📞 22:11, 7 October 2019 (UTC)
  • Leaning towards support, but some questions: can DjVu files be converted to another format without serious issues? And are there any possible sources for freely licensed DjVu files around which haven't been imported to Commons yet? - Alexis Jazz ping plz 19:05, 7 October 2019 (UTC)
Based on the comments below, I'm not convinced there are suitable/easy alternatives right now. - Alexis Jazz ping plz 11:26, 8 October 2019 (UTC)
But the question is can a bot automatically convert files to PDF? Masum Reza📞 22:13, 7 October 2019 (UTC)
Following what is written below I cannot stand behind what I wrote and removed it from the discussion by striking it. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 17:17, 8 October 2019 (UTC)
  • A quick search gave me File:प्रियप्रवास.djvu and File:Los sueños - Tomo II.djvu imported from IA and File:The Bohemian Review, vol1, 1917.djvu imported from Hathitrust today and yesterday. I generally don't upload ebooks, are there reasonable alternatives for these cases with similar quality? (I saw for one that IA did offer a PDF, but that was 10 times smaller so perhaps not the same quality) - Alexis Jazz ping plz 22:19, 7 October 2019 (UTC)
    • Both Hathitrust and IA allow downloading as PDF. In fact, Hathitrust doesn't even offer a DjVu download option, so I'm not sure how that file ended up as a DjVu unless it was converted from PDF to DjVu by the uploader. I'll ask the folks at IA about the quality of their PDFs vs DjVu files and try to find out why the PDF files are so much smaller. Kaldari (talk) 22:52, 7 October 2019 (UTC)
      • @Alexis Jazz: Actually it looks like the PDF versions on IA aren't necessarily smaller. File:Los sueños - Tomo II.djvu (which was uploaded from IA) is 9.73 MB, while the PDF at IA is 18.9 MB, or basically twice as big. I'm not sure why the PDF for File:प्रियप्रवास.djvu is so much smaller. How do some other DjVu files compare? Kaldari (talk) 03:11, 8 October 2019 (UTC)
        • For equal quality, DjVu is generally going to be smaller due to more advanced (and complicated) format features and compression algorithms. For files found in the wild, PDF files are going to tend to be smaller because they are almost universally of lower quality. Once you need to doctor the text layer of the file (because the original OCR was missing or broken; or MediaWiki chokes on it, as it tends to do, since that bug too sits untouched in Phabricator), the almost universal answer (mostly due to Google's truly craptacular job scanning works) is that PDF files are useless. In every single case I've actually ran into, I've had to go back to original .jp2 images and do the OCR on them to get reasonable results. At which point it is much much easier to generate a new DjVu file then try to fix the PDF. Better tools for working with PDFs would alleviate this some, but I suspect limitations of the format would still apply. DjVu files, on the other hand, can be readily doctored and in practice, in my experience, tends to produce OCR-able extracted page images when needed (unless they've been artificially capped to get around the 100MB upload limit here or similar). --Xover (talk) 09:22, 8 October 2019 (UTC)
          • @Kaldari: As for " I'm not sure how that file ended up as a DjVu unless it was converted from PDF to DjVu by the uploader" ... yes, that is right: I have uploaded that file from Hathitrust and converted it to DJVU, because Phabricator is not willing or able to fix the broken OCR tool and so I have to rely on the original OCR layer, but MediaWiki is not able to extract it properly from PDFs, while after conversion to DJVU the results are amazingly better. --Jan Kameníček (talk) 19:00, 8 October 2019 (UTC)
  • Symbol oppose vote.svg Oppose DjVu files work better than PDF on Wikisource, due to reasons of the Wikimedia software that are largely out of our control. That is why people are still uploading DjVu files, including converting them from PDFs.--

Prosfilaes (talk) 04:13, 8 October 2019 (UTC)

  • Symbol oppose vote.svg Oppose Hold the phone! DjVu has features of the format that do not exist in PDF (not even PDF/A, so far as I know). The tooling for working with DjVu files has functionality that I have yet to find in tooling for PDF files (and, btw, I'm not sure what Kaldari was smoking when claiming DjVuLibre hadn't been updated since 2015 while linking to a thread discussing using a 2017 release, and which also, by the way, suggests the problem discussed is most likely an OS bug affecting more than just DjVu. Did I mention the WMF has open bugs in MediaWiki core that dates back to 2005? I guess it's time we migrate away from it. I hear Atlassian has nice tools for a small fee. Or there's always SharePoint. What do you say?). And that's just the off-the-shelf tooling, in addition to which is the investment in custom tools that the community has made (since we can't get the WMF to assign any resources to Wikisource). And it really doesn't help that MediaWiki botches even the format features that are actually available in PDF resulting in crappy OCR text layer extraction (which is probably at least partially fixable if the WMF would actually assign some resources to…). For the Wikisources, PDF is a second-rate alternative you use in a pinch and definitely not the preferred choice.
    In order to migrate to PDF we would need to resolve all these issues first. At which point, the effort required to find and fix the relevant bugs (if there are any) in DjVuLibre is probably far less. Given we have extremely simple fixes (two-line diff to PHP code) sitting untouched in Phabricator for DjVu text extraction, the probability of getting the PDF support fixed seems pretty much nil; and that's the small and easy first step.
    While, yes, there is a concern regarding the DjVu ecosystem and risks that the tools will stagnate and bitrot eventually, there is currently no credible alternative for our purposes. I suggest energies are directed towards finding better solutions that people will want to migrate to, rather than trying to outlaw "stuff I don't like". Because it's currently enough of a hassle to keep our media on Commons given various impedances (policy, purpose, culture, etc.) and deprecating our primary and preferred format will affect that calculus significantly.
    PS. @Kaldari: Since I happen to know that you're aware of Wikisource's existence, I've got to say making this proposal here without notifying the projects most affected by it is a bit of a crap move. Thank you to Donald Trung for taking the time to notify English Wikisource; and now we've got to go notify the remaining 70 language-specific Wikisources that will to various degrees be affected by this. --Xover (talk) 09:07, 8 October 2019 (UTC)
Concur with Xover. Worse than a crap move, pretty insulting.  — billinghurst sDrewth 09:59, 8 October 2019 (UTC)
@Xover: I would be very happy if I was wrong, but I can't find any version of DjVuLibre newer than 2015. There are some bundles with newer versions of DjView, but I don't see any newer versions of DjVuLibre. Where is this 2017 version you speak of? Kaldari (talk) 17:44, 8 October 2019 (UTC)
@Kaldari: I didn't do too much digging, so I won't venture into distinctions on what exactly constitutes a "new version" of what, but in one of the bug threads you linked above, from 2017, they referred to a then-new version and compared results with the 2015 version. I didn't check whether that was of the library or the viewer (or a bundle). In any case, the last commit to DjVuLibre's Git repo was on September 10, 2019. And I'll note that DjView 4.10 works just fine on my macOS 10.14.6; as do whatever the Homebrew version of the command line tools is (different box, can't check just now). --Xover (talk) 18:01, 8 October 2019 (UTC)
@Xover: I was trying to use DjView 4.9 which won't even launch in High Sierra (which is a 2 year old operating system). 4.9 is the most recent binary release but I guess I can try building 4.10 myself. Kaldari (talk) 18:54, 8 October 2019 (UTC)
@Kaldari: Try 3.5.27+4.10.6qt57c (released October 7, 2017). I'm pretty sure that's the version I'm running. --Xover (talk) 19:03, 8 October 2019 (UTC)
@Xover: It works! Thank you! I take it all back. DjVu is fine ;) Kaldari (talk) 19:30, 8 October 2019 (UTC)
  • Symbol oppose vote.svg Oppose Really premature proposal. Although generally I agree that DJVU is dead and libraries also switched to PDF, Wikimedia software for some reason prefers DJVUs which work better at Wikisources than PDFs. What is more, Wikimedia programmers are also not very accustomed to PDFs as well: when the last technical problem with PDFs appeared (in June 2018), it took many months before they were able to solve it (in February 1919) – if there were no DJVUs, Wikisources would be paralyzed. For these reasons I oppose the proposal until Wikimedia environment gets friendlier to PDFs. --Jan Kameníček (talk) 11:35, 8 October 2019 (UTC)
  • Symbol oppose vote.svg Oppose As said above, there is a lot of technical work to be done before PDF can fully replace DJVU, especially on Wikisource. I'd be open to deprecating DJVU when PDF becomes a viable alternative, but that is still a long way off. -- Beleg Tâl (talk) 12:19, 8 October 2019 (UTC)
Symbol oppose vote.svg Oppose Spent an inordinate amount of time trying to work with PDF files from Internet Archive and they are terrible!!!
  1. Most if not all were donated by Google and the quality is very poor.
  2. Google removes photos. When they do include it it's impossible to clean and resize.
  3. As stated above, .Djvu is much cleaner to read and the images are superior. Please see my upload contributions.
  4. Please don't declare it dead, instead, fix the damned OCR from Phe.— Ineuw talk 21:14, 8 October 2019 (UTC)
  • Symbol oppose vote.svg Oppose Depreciate, maybe. An removal of an file format needs to be considered with the sister projects in mind. In this case wikisource uses djvu files extensively. Sure, Internet Archive does not make OCR DjVu files, but there are extensions for Tesseract, namely gscan and ocrdjvu who have both been updated in this year (2019) and through them Wikisource editors still can make OCR DjVu files. On wikisource the support for djvu for readers is irrelevant, because that is not the end result of the work at wikisource. Instead the books are shown with on-wiki with the option to make epub, pdf and mobi files through wsexport.--Snaevar (talk) 22:52, 8 October 2019 (UTC)

DjVu is dead. We should deprecate it for new uploads. (Discussion)[edit]

As this concerns Wikisource, I've left a message at their Scriptorium (for smaller screens). Maybe they can figure out an alternative or just switch to .pdf files. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:06, 8 October 2019 (UTC)

  • Pictogram voting comment.svg Comment DjVu is dead? Is it really? Arguments pointed by Kaldari are a bit general and can partly apply to other formats (for instance SVG 2.0 has a complicated history since 2013) or untrue (other places still use DjVu, a lot of digital libraries still provide it, even if IA stop generated them in 2016) and to be honest, it has never really been alive, since the beginnings it's a niche format. My main question is: how alive is DjVu in the Wikimedia ecosystem? For instance, can we have the number of uploads per year/month on Commons? (can it be done with quarry?) and what do the Wikisourcerors think? (as we/they are the only users of DjVu) If we deprecate the format, will the Wikisourcerors just upload them locally on their Wikisources instead of Commons (which will only create more problems). Then, and only then, there is all the technical details. Cheers, VIGNERON (talk) 08:57, 8 October 2019 (UTC)
  • Symbol keep vote.svg Keep DjVu files are used by the Wikisources, and are within scope. Commons is not here to determine what the other sites should use, it is here to host the files for the sisters that are within scope.  — billinghurst sDrewth 09:56, 8 October 2019 (UTC)
  • Gif is dead. Hasn't been updated since 1990. Deprecate it too. (sigh) Jarnsax (talk) 14:34, 8 October 2019 (UTC)
As a serious comment, what is missing from this proposal is any actual reason to deprecate a format that is used, and fully supported. Jarnsax (talk) 14:50, 8 October 2019 (UTC)
@Jarnsax: The reason, as I mentioned, is lack of good software support for viewing, creating, and editing DjVu files locally. The small amount of software that does exist is no longer being supported or updated, so it is becoming increasingly hard to actually work with DjVu files (unless you just stop updating your operating system). This problem is only going to get worse. GIFs are another story as they are widely supported by hundreds of programs on all platforms. Kaldari (talk) 15:50, 8 October 2019 (UTC)
@Kaldari: So your answer is to break Wikisource? Your proposal is to remove existing, working functionality, with no actual working replacement, on the theory that what actually works now might break someday in the future. The sensible answer would simply be to not break things... go actually do the work to duplicate the existing 200,000-odd existing files as PDFs (if you think the lack of them as PDFs is a problem), do the work to actually make PDFs work properly here and on Wikisource, then start automatically converting uploaded DJVU files to PDFs, and deprecate them if or when they actually break. Note that PDF/A is currently explicitly broken. Jarnsax (talk) 17:44, 8 October 2019 (UTC)
Then your operating system sucks. If it works today with Windows, Microsoft has basically pledged to support it indefinitely, to make Windows 10 the final version of Windows. Linux doesn't gratuitously break old software either. I don't really see a day when DjVuLibre stops running on those systems.--Prosfilaes (talk) 01:28, 9 October 2019 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Improving MediaWiki's PDF support[edit]

From the feedback above, it sounds like better PDF support in MediaWiki would be a pre-requisite to ever deprecating DjVu support. Can you provide a rough idea of which issues with PDF support should be the highest priority? Maybe we can put together a wishlist proposal for this year's Community Wishlist (which is specifically limited to non-Wikipedia projects). Even if we never deprecate DjVu, we still have to face the fact that software support for it is slowly dying and we're going to need alternatives in the future. Kaldari (talk) 17:33, 8 October 2019 (UTC)

@Prosfilaes, Xover, Jan.Kamenicek, Beleg Tâl: ^. Kaldari (talk) 17:46, 8 October 2019 (UTC)
Issues I've noticed:
  • Match and Split does not work at all
  • Image in proofread interface are lower quality than they should be given the quality of the PDF file itself (more so than DJVU) (edit: phab:T224355)
  • Ability to move and resize the image in proofread interface does not work sometimes for PDF
Beleg Tâl (talk) 18:13, 8 October 2019 (UTC)
And as Xover has mentioned above, OCR layer extraction is much much worse with PDF than with DJVU. --Jan Kameníček (talk) 18:38, 8 October 2019 (UTC)
Highest priority should be fixing extraction of an existing OCR text layer from PDF files. Currently there is something in how that's done that produces markedly poorer results than opening the PDF in Acrobat and copying the text out (there are some tests on enWS from earlier this year, but I don't have the link handy). This is where MediaWiki actually falls down regarding PDF. Second priority would be fixing PDF/A support (phab:T188885) because this is what several archives and repositories use. Plus the issues Beleg Tâl brings up above.
But the biggest hurdles aren't in MediaWiki. I've yet to find a toolset for PDF that comes anywhere near what DjVuLibre provides for DjVu files. I can construct and manipulate DjVu file programatically to my heart's content, including creating them from page scan images including structurally tagged OCR text; inserting, reordering, or removing pages; redacting whole or partial pages; combine multiple DjVu files; etc. In fact, I'm currently investigating setting up something toolserver-y that others can use based on my local hacky scripts; most critically to provide ad hoc per-page OCR since the current best tool is down (T228594), but also, hopefully, to interactively manipulate DjVu files (inserting or removing missing or duplicated page scans is a common need (see Google's utter lack of care when scanning)).
I would also be significantly concerned about format features. DjVu was designed specifically for our use case, so it provides separation of background (the empty space of a page) and foreground (the text) into separate layers, structured storage of annotations and hidden text layers (see e.g. djvused), and a wavelet-based compression system that gives you both good compression, high performance, and a reasonable lossylossless compromise (I'd say, informally, we're in JPEG territory for visible artifacts; but much much better on recompression, which is some times needed). PDF is oriented solidly towards print production (it's based on PostScript, after all) and so it is clearly superior for born digital works (it can reproduce a lot of the features of word processing and typesetting software), but suffers from significant impedance mismatch for representing the scanned print works that are our bread and butter on Wikisource. Without a deep-dive I won't go so far as to claim the format is inherently harder to work with for our purposes, but anyone that's ever tried editing PostScript by hand will at least admit it is a valid thing to be worried about. And my search for existing tools to work with PDF in the same way DjVuLibre provides for DjVu files only tends to reinforce that impression. I hold it entirely possible that PDF as a format will always be inferior to DjVu (though good tooling can compensate for that).
And just to be clear, I share your concern about the software ecosystem for DjVu. For the long term this is a problem, and long term it may necessitate migrating away from DjVu. But as of right now the DjVu tools exist, work well, do not appear in imminent danger of stopping working (there are 64bit binaries available, for example), and there are no credible alternative formats. --Xover (talk) 19:29, 8 October 2019 (UTC)
Thanks for all that info. Also, as Slowking4 mentioned on Wikisource, we would want to make IA Uploader produce PDFs before we ever deprecated DjVu. Kaldari (talk) 15:30, 9 October 2019 (UTC)

Acceptance of files from external sources without a license review[edit]

We have an endless number of files from external sources without a license review. Many have been around for many years, many of the links died. Thanks to Donald Trung's proposal to archive all external links, this shouldn't be a common sight anymore from now on. But we still have all those old files that were never reviewed. Deleting everything makes no sense. Pretending license reviews are not needed makes no sense. This proposal does not apply to files without a source, a source that still works or a source that can be checked through or similar means.

Proposal to keep files with a source that is no longer available and that:

was uploaded by a former or current license reviewer, administrator or OTRS-member


matches all of the following:
  • Has a similar or identical source to files with a license review or uploaded by the groups above (for "", "" would be similar)
  • Matches the general style of those files. Locations, subjects, time period, photography/art style, EXIF if present, watermarks. Not every single thing needs to match, but we should be convinced the work is from the same source.
  • Comes from a source with a general waiver or license (no exclusion of specific files, or only exclusion based on criteria that we can tell without having the source available, for example: "the license only applies to photos taken in Italy")
  • Uploaded by a user who is not known for copyfraud.

These files will be marked as "This file was uploaded by a trusted user" and won't require a license review. - Alexis Jazz ping plz 17:41, 13 February 2019 (UTC)

Acceptance of files from external sources without a license review: votes[edit]

  • Symbol support vote.svg Support. Note: Donald Trung, Roy17 and Yann have not voted yet in this section because this proposal was copied from my user space and the voting section didn't exist there yet. - Alexis Jazz ping plz 14:42, 8 October 2019 (UTC)
  • Symbol support vote.svg Support: I like this idea. -- Tuválkin 16:28, 8 October 2019 (UTC)
  • Symbol support vote.svg Support, obviously things like "COM:PCP" will override this where necessary, but we really need to have a bot archive all the external links by now. This is the best solution for these older files. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 17:20, 8 October 2019 (UTC)
  • Symbol support vote.svg Support I can't understand why license reviewers (LRers) need to review uploads by other LRers. This seems to be a waste of time in my opinion, considering the low error rate. I have reviewed about 5K images so far. I hardly remember failing a file uploaded by a LRer. They should focus on files uploaded by other users (non-LRers). 4nn1l2 (talk) 11:34, 10 October 2019 (UTC)
  • Symbol support vote.svg Support.--Vulphere 04:05, 16 October 2019 (UTC)

Acceptance of files from external sources without a license review: discussion[edit]

Discuss details for this proposal here.

  • @: I know you made a similar proposal not too long ago. Any comment? - Alexis Jazz ping plz 17:45, 13 February 2019 (UTC)
  • I've been following File:31i-US-2 (警察との共同訓練(緊急輸送訓練)) R 教育訓練等 53.jpg. It's too difficult or simply impossible to verify old linkrots like this. I will support a resolution to relax a bit on linkrot files that meet the following criteria: 1. well-known/large-scale linkrot like picasa, lasvegasvegas, farsnews, etc.; 2. uploaded a long time (3 years?) ago. Such files should not be deleted for the vague no source/no permission/... Only credible claims of copyright issues (the photographer can be identified, an external copy can be found, or a complaint is made...) can lead to deletion by DR.--Roy17 (talk) 14:07, 17 February 2019 (UTC)
@Roy17: Category:Chama Ice Cave from farsnews was uploaded in December 2018. For that reason, I didn't include a fixed time period like 3 years because nobody can predict linkrot. - Alexis Jazz ping plz 17:20, 17 February 2019 (UTC)
  • I would Symbol support vote.svg Support this as I had supported the original proposal by Fæ, if my proposal gets accepted this proposal will probably not be needed for newer files as they'll have archived external links, but as this practice hasn't been adopted yet many links have become useless. Though all these users most certainly aren't perfect, it beats deletion. I still think that we should've utilised the Internet Archive Bot years ago. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:42, 17 February 2019 (UTC)
@Donald Trung: Good point, that's why I have an incubator. I'm going to wait for your proposal to pass. After that, this will be more of a "grandfathering" proposal, which I think is more likely to be accepted. Fæ's proposal was too specific and not really worked out. Fæ said to "vote on the principle", but that's generally not what VPP is for. - Alexis Jazz ping plz 21:02, 17 February 2019 (UTC)
  • This looks reasonable. Yann (talk) 04:21, 22 February 2019 (UTC)

Offer a method to view and edit MIDI files online[edit]

The MIDI Files category only has 946 files. Most of them are more than 10 years old, and many of them only have a few seconds of audio.

One reason for the low participation in this category is that there was previously no method to view and edit a MIDI file online; you had to download a program.

The first Online Midi Editor was created two years ago, and it was recently moved to a new domain:

I would like to request permission to create a page in Commons which describes, since it is the only Online Midi Editor on the entire web. I noticed that the VicuñaUploader received its own page in Commons, and a special mention on the Commons 'Welcome' page (under 'Additional services and software').

I would also like to propose adding a link to each midi file's thumbnail and profile, which will import and display that midi file at For example, the following link displays the midi file for "Giant Steps" by John Coltrane:

This will be very simple to implement. The link from WP to will include a 'wp_url' parameter, which will allow to import and display that midi file.
— Preceding unsigned comment added by ToolCreator (talk • contribs) 8 October 2019 21:00 (UTC)
  • I personally have no issue with a page that describes how to use, as long as it's educational. If there are people who would find this useful, a gadget could probably be created to link to with a file from Commons loaded. There are 5,645 MIDI files on Commons by the way.- Alexis Jazz ping plz 01:10, 9 October 2019 (UTC)
  • I feel the same way as Alex. But that website literally doesn't have any API or anything of the sort. At least I couldn't find any similar features either. It doesn't even support upload by URL, meaning files have to be uploaded by a user's device. So creating a gadget might be a difficult task. Masum Reza📞 01:38, 9 October 2019 (UTC)

This URL ( displays "The following 200 files are in this category, out of 946 total." Please indicate why this count differs with your search, which showed "5,645 MIDI files on Commons".

I can provide an example which shows how can import and display the midi file when the following URL is sent as a GET parameter:

I can also create an educational webpage which describes how to use with midi files received from Commons.

Before doing so, please confirm that my efforts will not be rejected for some other reason (like "insufficient citations"). I'd hate to waste my time.

I enormously appreciate your positive response to my proposal, thank you! ToolCreator (talk) 02:23, 9 October 2019 (UTC)

Commons generally doesn't
@ToolCreator: Because not all MIDI files are in that category. For example, Category:MIDI files of music by Johann Sebastian Bach has 78 files in it. (and its subcategories another 21) Citations are no issue. We'd mostly be concerned about whether or not something is in scope. A general page about MIDI would be better suited for Wikipedia or Wikibooks. For general instructions for a universally known tool like Photoshop, Wikibooks is probably best. Of course, it should be relevant for Commons. For example, the checklist on COM:Colorization is relevant. And finally it shouldn't be spammy. Considering appears to be ad-free and not selling subscriptions, I'd say that's fine. - Alexis Jazz ping plz 03:16, 9 October 2019 (UTC)
@Alexis Jazz: The example I described will be shown here tomorrow (which will import and display the midi file when the URL is sent as a GET parameter to How long will it take for an [Edit MIDI] link to be added to each midi file's thumbnail and profile at Commons? ToolCreator (talk) 03:27, 9 October 2019 (UTC)
@ToolCreator: No links will be added directly to files. A gadget could be made for this (not by me, I lack the knowledge) which could be enabled by users who want it. It shouldn't be too hard though because we already have gadgets for Google Images and Tineye which do the same kind of thing. - Alexis Jazz ping plz 03:39, 9 October 2019 (UTC)
@Alexis Jazz: I can create the gadget. I just don't know how to send a GET request to that website. @ToolCreator: Please show us an example. What are the GET parameters, and call URL? Masum Reza📞 08:01, 9 October 2019 (UTC)

The following two URL's demonstrate how can import a MIDI file from Commons:

Each MIDI file's download address can be found on the file's Commons webpage, under "File history" in the "Date/Time" column. For example:,_No._1.mid

You can create [View MIDI] links to, by adding each MIDI file's download address to the right of "?wp=" in the outgoing link URL.

I think [View MIDI] would be a better caption for the links, instead of [Edit MIDI].

Please let me know if you have any questions. ToolCreator (talk) 19:54, 9 October 2019 (UTC)

Folks can use for the past 6 years, the Score extension to get MIDI files out of Lilypond notation. Wouldn’t that be one of reasons we have few MIDI files? Jean-Fred (talk) 20:05, 9 October 2019 (UTC)

@Masumrezarock100: @Alexis Jazz: I created the page for ( I think you will find it to be educational. Let me know if you need anything else to create the gadget. ToolCreator (talk) 03:26, 10 October 2019 (UTC)

@ToolCreator: Very nice! I moved the page to (we keep help pages in the Commons: namespace) - Alexis Jazz ping plz 03:29, 10 October 2019 (UTC)
I've created a pretty basic version of the gadget based on the TinEye gadget. But it is for some reason, loading on image file pages instead of mid file pages. It is located here. I can't seem to figure out where I made a mistake. We'll need to work on it more. @Perhelion: perhaps you can lend me a hand? Masum Reza📞 06:01, 10 October 2019 (UTC)
Masumrezarock100, try this:

/* OnlineMidi gadget code start.
Depends on mediawiki.util. */
$.when(mw.loader.using('mediawiki.util'), $.ready).then(function () {
'use strict';
if ( mw.config.get('wgNamespaceNumber') == 6 && mw.config.get('wgAction') === "view" && document.getElementById('file') ) {
var mid = document.getElementsByClassName('fullMedia')[0].getElementsByTagName('a');
var midURL = mid[0].href;
//Conditionally add the portlet link
if (midURL.substr(midURL.length - 4, midURL.length).toLowerCase()  == '.mid'){
mw.util.addPortletLink('p-cactions', '' + encodeURIComponent(midURL), 'Edit MIDI', 'ca-midiedit', null).children[0].target = '_blank';
I needed to change the element to source/construct the actual media url from, and added a condition. It should only activate if the extension is .mid. I tested the generated url at onlinemidi for a couple and it seems to work. You might need to tinker with the condition if you need to allow for any different extension, but that should be easy enough to do... -- Begoon 09:39, 10 October 2019 (UTC)

@Masumrezarock100: @Alexis Jazz: Thank you for your efforts. I think everyone will want to view the midi notes, so I hope you can make this gadget run by default. Otherwise, very few people will know that this feature exists.

Also, please mention on the Commons Home or Welcome page. I noticed that VicuñaUploader received a special mention on the Commons 'Welcome' page (under 'Additional services and software'), so I hope that OnlineMidi has the same relevancy. If more people knew about the capabilities of MIDI files (as demonstrated by the Sample Midi Files listed at, then you would receive more new submissions.

It is an honor and a pleasure helping your fine organization. ToolCreator (talk) 12:41, 10 October 2019 (UTC)

@Begoon: Thanks for fixing the bug. It is working fine now. We can move the script to Mediawiki gadget namespace once this discussion is closed. @ToolCreator: For now, copy-paste the following code to your Special:MyPage/common.js to install the script. Masum Reza📞 14:39, 10 October 2019 (UTC)
mw.loader.load('//'); //OnlineMIDI
@Masumrezarock100: The link you provided (Special:MyPage/common.js) displays "This page does not currently exist." ToolCreator (talk) 15:10, 10 October 2019 (UTC)
It should say "This page does not currently exist. You can search for this page title in other pages or create this page." and the words "create this page" are a link, which you can click to create the page. -- Begoon 15:16, 10 October 2019 (UTC)
Yes, create the page with the code I posted. Navigate to a mid file, and click the more collapsible drop-down. And you should see a Edit MIDI link. Masum Reza📞 15:20, 10 October 2019 (UTC)
@Masumrezarock100: Yes, it works, thank you! What is the process to make this a default gadget? ToolCreator (talk) 15:29, 10 October 2019 (UTC)
@ToolCreator, Begoon: I went ahead and optimized this script for mobile. It should now load on the mobile website. Head over to a mid file on the mobile website (eg.,_No._1.mid), and you should see a similar button. Regarding making it a gadget, as I've said, it will be moved to the Mediawiki gadget space once this proposal is accepted. Masum Reza📞 16:09, 10 October 2019 (UTC)
@Masumrezarock100: You may not want the link to appear on the mobile website, because the midi editor requires more screen space than most mobile devices can handle.
@Masumrezarock100: Just so I know how often to check back, how long does it usually take for a proposal to be accepted? This page lists 11 Gadgets ( Is there another page that lists more? ToolCreator (talk) 16:57, 10 October 2019 (UTC)
Ah, I didn't think about that. It makes sense to me. We can change it's definitions so that it won't load on the mobile. However, I suggest the Minerva skin part to be kept, since there are some users who use Minerva skin on desktop site. On English Wikipedia, a discussion usually takes place for minimum 7 days. You can assume the same for Commons. All gadgets on Wikimedia Commons are listed at Special:Gadgets. -Masum Reza📞 17:16, 10 October 2019 (UTC)
What is the sort order of midi files that are shown at Can the user select a different sort order? ToolCreator (talk) 15:18, 10 October 2019 (UTC)
Alphabetical order. Unless I am mistaken, there is no way to sort out files in a category at the moment. Perhaps a gadget could be created to support changing sort order. Masum Reza📞 16:09, 10 October 2019 (UTC)

I do not endorse making special mentions and/or creating a default gadget to a proprietary tool that does not even have a privacy policy. If one uses this tool to edit MIDI, then it is their own choice. --Zhuyifei1999 (talk) 17:21, 10 October 2019 (UTC)

@Zhuyifei1999: Please describe the additions you would like to see in the Terms of Use for, to satisfy the requirement for a privacy policy. Please also provide the address of the page that lists default gadgets. Thanks! ToolCreator (talk) 17:31, 10 October 2019 (UTC)
Oh, that would be fun:
  • "Proprietary": Release your source code under FOSS license
  • "Privacy Policy": List clearly what data you will collect from end users, and explain what you will do with the data, and under what circumstances will you release the data to third parties. See foundation:Privacy_policy for an example.
The list of gadgets are at Special:Gadgets. The default ones are listed with "Enabled for everyone by default." --Zhuyifei1999 (talk) 17:51, 10 October 2019 (UTC)

@Zhuyifei1999: Thank you for your advice. I added the following Privacy Policy to the Terms of Use for

Privacy Policy for No information whatsoever is collected from users of the Site without their permission. No information is sent to the server while the user is using the Site, other than the HTTP parameters that are sent to all websites (IP Address, Browser Type, and Referrer). Those parameters shall never be released to any other entities. If a User chooses to Register (which is not required), the information they submit (Email, Username, Password, and URL) shall never be released to any other entities. Cookie Usage: Cookies are only used when the [Remember me] box is checked when a registered user logs in. The Site does not use Cookies for any other purpose whatsoever.

Regarding the Proprietary nature of the website: The Midi Editor and Player are entirely run from the browser, using client-side javascript. There is no server-side processing whatsoever. Anyone can click 'view source' in their browser to see all the code that the website uses.

After reviewing the gadgets that have been "Enabled for everyone by default", it appears that this proposed gadget meets the same standards as those gadgets. If that is not the case, then please indicate any other changes that I should make. ToolCreator (talk) 18:41, 10 October 2019 (UTC)

Not releasing any information... including law enforcement?
By under 'FOSS' I mean 'free and open source software', free as in libre, free as in free speech, not free beer. We need the right to run your code for any purpose, study your code, modify, fork, redistribute, for any purpose, including commercial, without restrictions. Your 'Copyrights' section clearly differs. --Zhuyifei1999 (talk) 19:02, 10 October 2019 (UTC)
I have the same concern. The policy of states

The All content included on the Site, such as text, graphics, logos, button icons, images, audio clips, digital downloads, data compilations, and software, is the property of or its content suppliers and protected by United States and international copyright laws. The compilation of all content on the Site is the exclusive property of and protected by U.S. and international copyright laws. No part of this program may be copied, reproduced, translated, or reduced to any electronic or machine readable form without the prior written consent of

Am I understanding it correctly that all media files taken from the website are copyrignted including the mid files uploaded to the the website after an user edits them? So let's say a user uploads a file to OnlineMidi, and then edits it using the website. Who is the copyrignt holder of the new (edited) file and what it is new license? We have a goal to provide free educational files. Does this website meets our licensing requirements? 19:12, 10 October 2019 (UTC)
@Zhuyifei1999: As per your suggestion, I changed the Terms of Use for to clarify that the user's data "...shall never be released to any other entities (unless legally ordered to do so)".
Regarding the justifiable concern that uploaded midi files would become the ownership of the site, I have added the following sentence to that paragraph: "This copyright does NOT include data that is created or uploaded by a user.".
There are other gadgets that have been "Enabled for everyone by default" which do not allow others to "redistribute, for any purpose, including commercial, without restrictions.", so that is apparently not a requirement. ToolCreator (talk) 19:31, 10 October 2019 (UTC)
"There are other gadgets that have been ... which do not allow others to ..." for example? --Zhuyifei1999 (talk) 21:02, 10 October 2019 (UTC)
@ToolCreator: I'm not a lawyer, but here's a suggestion:
This service embeds content from which may use cookies and collect the data from your HTTP-request. Please refer to the Soundcloud privacy policy for details. may log the information that results from requests (like HTTP-requests) to the service like IP address, user agent and referrer. This information may be used to generate statistics and detect abuse of the service. only uses functional cookies. When the user registers an account, their information like e-mail address, username, password hash and any other entered information will be stored by None of the aforementioned information that is collected by will be shared with third parties unless required by law.
Again, I'm not a lawyer, but this is probably more likely to be legally sound than the current text. Also, make sure you actually are storing password hashes and not passwords like your policy currently states.. - Alexis Jazz ping plz 11:27, 13 October 2019 (UTC)
@Alexis Jazz: Thank you for your advice. I changed the Privacy Policy as per your suggestion:ToolCreator (talk) 12:54, 13 October 2019 (UTC)

Revised Privacy Policy for This service embeds content from which may use cookies and collect the data from your HTTP-request. Please refer to the Soundcloud privacy policy for details. may log the information that results from requests (like HTTP-requests) to the service like IP address, user agent and referrer. This information may be used to generate statistics and detect abuse of the service. only uses functional cookies. When the user registers an account, their information like e-mail address, username, password hash and any other entered information will be stored by None of the aforementioned information that is collected by will be shared with third parties unless required by law.ToolCreator (talk) 12:54, 13 October 2019 (UTC)

@ToolCreator: The help page of OnlineMidi on Wikimedia Commons contains 99% of copied words (according to copyvio detector tool). Your website states that even texts are copyrignted. Please license it to us and update your Copyrignt policy, or rewrite the whole help page on Commons using your own words. Pages with excessive copyrighted are subject for speedy deletion per G11 criteria. Thanks you for your understanding. Masum Reza📞 21:31, 10 October 2019 (UTC)
@Masumrezarock100: I modified the Terms of Use for to indicate that Wikipedia Commons has permission to re-publish text from the Help page ( Do I need to take any other action regarding this issue? ToolCreator (talk) 21:56, 10 October 2019 (UTC)
So here's the thing, Wikimedia Foundation provides free access to open knowledge and allows anyone to use it's content. As you might have noticed, the footer of every pages has the following text.

Files are available under licenses specified on their description page. All structured data from the file and property namespaces is available under the Creative Commons CC0 License; all unstructured text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply.

As Wikimedia Commons is one of Wikimedia Foundation's projects, anyone can copy, modify, and distribute its content (which are hosted on this site), or use it for any other purposes (even for commercial purposes), provided he/she abides by the terms of licensing. You gave only Wikipedia and Commons to use your website's content. So if I were to copy/use the texts from the OnlineMidi page on Wikimedia Commons, it would be a copyrignt violation, because I don't have permission! You see what I mean? Unfortunately Wikimedia projects can not host such content. Please update your Copyrignt policies and license it under one of the free licenses. Masum Reza📞 22:19, 10 October 2019 (UTC)
@Masumrezarock100: Please provide the proper wording that I can add to the Terms of Use for, to indicate that the text from the Help page is properly licensed to appear on the Commons page.ToolCreator (talk) 22:35, 10 October 2019 (UTC)
The wording depends on what license you choose. It is generally recommended to license it under one of the Creative Commons licenses. There are plenty of CC license tags that you can use. See Category:CC_license_tags. Masum Reza📞 22:53, 10 October 2019 (UTC)
@Masumrezarock100: If I place the following statement in the Terms of Use, will that suffice:

The Help page ( is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike CC BY-NC-SA License ( ToolCreator (talk) 23:20, 10 October 2019 (UTC)

Ah, drop the non-commercial part. Commons doesn't allow Non-commercial and non-derivative works licenses. Also why only freely license the help page? It doesn't hurt to license all texts of the website under a free license. Those are just simple texts nothing special. Masum Reza📞 23:26, 10 October 2019 (UTC)
@Masumrezarock100: The website says "This is the license used by Wikipedia", so I assume this will work. Do I have to do anything other than adding this sentence to my Terms of Use webpage?

The Help page ( is licensed under the Creative Commons Attribution-ShareAlike CC BY-SA License ( ToolCreator (talk) 23:43, 10 October 2019 (UTC)

It doesn't explicitly states what license Wikimedia Commons uses. Per COM:L, ND and NC licenses are not acceptable on Commons.
Do readers a favor and clearly state how text portion in the help page can be used and what is it's copyrignt status. Just simply linking to a CC license page doesn't help. See Template:CC-by-sa-4.0 for an example. Masum Reza📞 00:04, 11 October 2019 (UTC)

@Masumrezarock100: I added the text from the template that you suggested, to the Terms of Use for Please see paragraph 8 in that document. I also added the following statement to "This page contains text from the Help Page, which is licensed under the Creative Commons Attribution-ShareAlike CC BY-SA License."

Please confirm that this issue is resolved. Thanks! ToolCreator (talk) 00:17, 11 October 2019 (UTC)

@Zhuyifei1999: The gadget itself will be 'free and open source software', as are all the javascript gadgets on the Special:Gadgets page. Each gadget is simply a javascript snippet that is free for anyone to use; that is a condition for the gadget to be placed on the Special:Gadgets page.

However, the websites, software, and data that the gadgets access are obviously not all 'free and open source software'. For example, if a gadget launches a PDF file, that doesn't mean that everyone can "redistribute, for any purpose, including commercial, without restrictions" all of Adobe's software.

Here are two examples of gadgets that are "Enabled for everyone by default" that access software and/or data that is not "FOSS":

1. "Email a link: Starts an e-mail with a link to the file and a credit line" This gadget must be launching email software that is not FOSS (like Gmail or Outlook).

2. "additional data courtesy of the US National Park Service, Landsat7 data courtesy of NASA." The US National Park Service and NASA do not allow others to "redistribute, for any purpose, including commercial, without restrictions" all of their data and software.

The proposed gadget will be FOSS: the javascript code will be FOSS. The site that it accesses ( has the Terms of Use for

You will be tremendously limiting the capabilities of gadgets if you do not allow them to access websites, software, and data that are not FOSS. ToolCreator (talk) 22:02, 10 October 2019 (UTC)

  • Stock photo does not explicitly launch any proprietary software. Some of us use FOSS email clients, such as Thunderbird to handle emails. If a client binds mailto: to Gmail or Outlook, then they are expected to be fully aware that they are using such service. Again, we don't endorse proprietary software; if you use them as your email client it is your choosing.
  • Since when has NASA claimed copyright? Maybe 'some' of their data and software, but the data being displayed is libre.
You claim that "the javascript code will be FOSS"; can I know what licenses they are under? --Zhuyifei1999 (talk) 22:36, 10 October 2019 (UTC)
You claim that "the javascript code will be FOSS"; if you mean that the gadget itself is FOSS, yes; however, setting it as a default gadget imply that we endorse your site. No, we don't endorse any specific proprietary software. --Zhuyifei1999 (talk) 22:45, 10 October 2019 (UTC)
I don't see any benefit in making this gadget default. If someone wants to use this gadget to edit MID files they should enable it by themselves. It would be just advertising your site if we make it default. Masum Reza📞 20:40, 11 October 2019 (UTC)

1. Can I use the midi player that is on your site to hear what a file will sound like before I upload it? 2. After I upload a file, can I delete or replace it?ToolCreator (talk) 17:43, 11 October 2019 (UTC)

  1. The MIDI -> waveform conversion is done by one of the two extensions: mw:Extension:TimedMediaHandler & mw:Extension:Score. I think you can either host a MediaWiki install yourself with these exiensions, and you can refer to our onfigueration. Another way would be that you can try to figure out what commands these extensions use to do the conversion by reading its source code.
  2. You can replace it by overwriting it with another file, but the file history will still be visible to public. For deletion, file a speedy deleion request --Zhuyifei1999 (talk) 19:21, 11 October 2019 (UTC)

I uploaded the following example, to show you what can do:

Please listen to this file at the following link, which the proposed gadget directs to:

You will see that this midi file includes audio for live drums, guitars, and female vocals. There is no other website that does this.

I noticed that nearly every midi file in your directory contains just a few notes (and usually only one instrument), which causes them to normally receive less than 5 page views in the past 30 days.

Many musicians would like to include your fantastic collection of audio files within their midi files, but if they don't know about OnlineMidi, then they won't know that they have that capability. I am friends with several film composers who would not use the OnlineMidi gadget unless it was a default gadget.

Your team has been fantastic in patiently guiding me through the WikiMedia process (which I am obviously new at). I sincerely believe that if this gadget is made to run by default, it will increase the quality of midi files in your directory. If it is not a default gadget, then very few people will know it exists. ToolCreator (talk) 01:43, 12 October 2019 (UTC)

Add galleries to deletion requests[edit]

Wouldn't that make them much easier to judge?

Obviously, galleries would only be visible on the DR page like Commons:Deletion requests/File:Example.jpg. They would not be included on overview pages like Commons:Deletion_requests/2019/09/30.

{{Delreqnom}} could be used for this. It needs a few tweaks, but it won't be deployed before those quirks are fixed. Here is an example of what a DR might look like. - Alexis Jazz ping plz 22:45, 8 October 2019 (UTC)

Add galleries to deletion requests: votes[edit]

  • Symbol support vote.svg Support - Alexis Jazz ping plz 22:45, 8 October 2019 (UTC)
  • Symbol support vote.svg Support -Masum Reza📞 01:35, 10 October 2019 (UTC)
  • Symbol support vote.svg Weak support, I like the idea, but as a mobile user this will mean minutes of scrolling per large deletion request. And some random IP that spots potential child pornography would probably nominate it for deletion because they don't know that speedy deletions exist, but I don't think (hope!!!) that much child pornography gets uploaded to Wikimedia Commons anyhow. There should be a way to (temporarily) disable these galleries for mobile users until we can collapse templates. This is also the only time when less functionality might actually benefit mobile users. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:22, 10 October 2019 (UTC)
  • Yes plz. Long overdue. I always copy a long list into, trunc the brackets, put it into a page and preview. This should be done by the suggested template or a gadget/script at least.--Roy17 (talk) 21:28, 10 October 2019 (UTC)
  • Symbol support vote.svg Support.--Vulphere 04:06, 16 October 2019 (UTC)

Add galleries to deletion requests: discussion[edit]

For many DRs, that would be helpful. If there are say 200 images, I'm less sure about that. And sometimes people mark comments on the end of the filename line, which you can't do in a gallery. But I guess you could do the same in that collapsed section. Carl Lindberg (talk) 23:18, 9 October 2019 (UTC)
@Clindberg: I made a template to dynamically switch between the list and the gallery plus hidden list while preserving comments: here is an example. @Masumrezarock100: that okay for you too? (template can be tweaked to make the gallery more appealing) - Alexis Jazz ping plz 02:19, 10 October 2019 (UTC)
I applied it to Commons:Deletion requests/Files found with "" (transcluded version) for testing, this works fine with delreqhandler (sort of important for admins Face-tongue.svg) too. The image width in the gallery needs to be adjusted. - Alexis Jazz ping plz 02:45, 10 October 2019 (UTC)
Hmm, the gallery layout could be improved. I suggest to make it's style more like Commons:Quality_images_candidates/candidate_list. Masum Reza📞 03:32, 10 October 2019 (UTC)
@Masumrezarock100: That would be nice, but that page also uses the gallery tag, which I can't use. And CSS makes my head hurt. {{Delreqnom/galleryitem}} is what needs to be improved btw. To do list on {{Delreqnom}}. - Alexis Jazz ping plz 04:01, 10 October 2019 (UTC)
@Donald Trung: Such uploads are rare as far as I know. I encountered it once (and reported it, it was only nudity IIRC, no interaction, though I didn't check the other uploads from the user), back when I was a newbie. I actually think it wouldn't have shocked me as much if I had only seen a gallery thumbnail. The gallery can be removed by editing the wikitext in individual cases anyway. (just remove "mode=gallery") It's possible to collapse the gallery, and this could be enabled/disabled with a gadget. I don't know if it is possible to make a template always behave differently on mobile. It would make sense to further restrict the maximum number of thumbnails on mobile. @Perhelion: do you know if that's possible, making mobile-specific tweaks? - Alexis Jazz ping plz 15:31, 10 October 2019 (UTC)
Pictogram voting comment.svg Some clarification, the main reason for adding "weak" to my support vote is actually not related to child pornography which is extremely rare on Wikimedia Commons (things like "the black web" or "deepweb" serve things like this), and Wikimedia Commons' new page patrollers (the general grouping of people, not just people with the user right) and the Wikimedia Foundation (WMF) actually handle it really well. I really like this idea as it will allow for people to make better decisions without opening lots of tabs. With "COM:SCOPE"-based deletion requests I expect this to be very helpful.
I actually only think that this might be bad when using the mobile browser view for "large" deletion requests, maybe we could make something like "<nomobile></nomobile>" that doesn't display when someone has the "Mobile view" enabled. But again, 99% (ninety-nine percent) of the time this gallery won't be a disadvantage, only with deletion requests that concern more than like 50 (fifty) or so files. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 17:51, 10 October 2019 (UTC)
@Donald Trung: Yes, I will be adding some limits. For mobile, I think there probably is a CSS class that would display:none on mobile but be ignored otherwise. I just don't know what the name of that class might be. If it doesn't exist, we could probably add it. This maybe won't stop the extra thumbnails from being downloaded (depending on your browser maybe), but they won't be displayed. - Alexis Jazz ping plz 14:34, 11 October 2019 (UTC)
@Donald Trung: if you add ".delreqgalover25, .delreqgalover50, .delreqgalover100, .delreqgalover200 { display: none !important }" to User:Donald Trung/common.css you'll never see more than 25 thumbnails. And with ".delreqgalunder25, .delreqgalover25, .delreqgalover50, .delreqgalover100, .delreqgalover200 { display: none !important }" you would see no thumbnails. This could be made into gadgets or default for mobile. - Alexis Jazz ping plz 07:27, 16 October 2019 (UTC)
@Roy17, Donald Trung, Clindberg: I changed some more things. Examples at User:Alexis Reggae/delreqnomsandbox and User:Alexis Reggae/delreqnomsandboxtranscluded. CSS guru for Template:Delreqnom/galleryitem still wanted to make it look prettier. Getting those comments/filenames on the same height is probably just a matter of a well-placed margin, align, padding or whatever.. - Alexis Jazz ping plz 04:11, 14 October 2019 (UTC)

Enable TinEye and Google images searching tool on mobile[edit]

TinEye and Google images search gadgets are very useful for users. It helps users to detect copyvio, similar images on web, and use of images outside Wikimedia projects, which are helpful to patrollers. These gadgets are not currently loaded on Mobile, mainly because mw.util.AddPortletLink isn't supported in Minerva, the only skin available on the mobile website. As a regular mobile contributor, I would like to use these two gadgets on the mobile website.


  • MediaWiki core provides a method mw.util.addPortletLink for adding menu items. But mw.util.addPortletLink is not available in minerva. Which is why many gadgets and scripts that uses this method doesn't work in Minerva. This issue has been tracked in phab:T231925.


  • Use plain HTML, CSS, and JavaScript codes to add the links or use existing methods like OOUI widgets.


Optimize the gadgets to make them work on mobile. I already prepared mobile versions of these scripts which are located at User:Masumrezarock100/googleimages-mobile.js and User:Masumrezarock100/tineye-mobile.js (merged version of these two gadgets).

  1. Option: Merge the gadgets together with desktop versions and add mobile target to the gadgets' definition.
  2. Option: Or Use the merged mobile script and add it as a separate gadget.



  • Option 3:
There is indeed no advance in splitting this 2 links (tineye/googleimages) with the very same meaning in 2 gadgets (in fact both need maintenance and more resources and one code is more functional than the other, the gadget settings are also getting growing and cluttering). So there would be this 3rd option in merging all. -- User: Perhelion 04:06, 10 October 2019 (UTC)
I am fine with it. Masum Reza📞 04:21, 10 October 2019 (UTC)
Symbol support vote.svg Support option 3. 4nn1l2 (talk) 10:48, 10 October 2019 (UTC)
@Perhelion: that new gadget is based on the same thing, merge all three? I also wouldn't mind enabling/disabling all three at the same time. I think most people enable/disable both reverse image search gadgets anyway. The odd duck who absolutely insists on disabling one or two of those could use CSS. - Alexis Jazz ping plz 15:14, 10 October 2019 (UTC)
@大诺史, Donald Trung:✓ OK I updated my scripts and links should now open in a new tab. Masum Reza📞 16:05, 11 October 2019 (UTC)

Add mobileUndo gadget[edit]

Undo feature in mobile website (Minerva skin) is a long sought feature. But it is possible to undo a diff using mobile website manually. Reading web team is currently working on Advanced mobile contributions project. They have added a undo button to history pages. But a undo button on diff pages is still missing. This task has been tracked in phab:T191706 but Reading web team isn't working on it despite it had been triaged as high priority. It is clear that there is a demand for this feature, see some related discussions on Mediawiki - mw:Topic:V8wxfm4a02x9glpw, mw:Topic:V77gwos6xmvslqz2, mw:Topic:V484smre28nqxvdh. In the meantime, FR30799386 has developed an user script to replicate this feature. There are many mobile contributors, but only a handful of them know about this script. Because of that many editors can not undo edits on mobile. We would like to implement this user script as a gadget. But I thought we should gain support from the community, and which is why I am proposing to make this script a gadget. Jon Robson also proposed the same thing on English wikipedia. All mobile users especially those who are active in countering vandalism and use mobile, will benefit from this. It works cross-wiki and also supports internationalization meaning it can be translated to one's preferred language. Thanks. Masum Reza📞 01:58, 11 October 2019 (UTC)

Add mobileUndo gadget: votes[edit]

  • Symbol support vote.svg Support as proposer. Masum Reza📞 02:01, 11 October 2019 (UTC)
  • Symbol support vote.svg Support, though I am certain that it will become the rule once "the Advanced Mobile Mode" will become the standard mobile mode, in fact I can't wait for the featureless Mobile mode to be completely abolished. Why is a dumbed down version of the MediaWiki software somehow "friendlier" for mobile users? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 05:48, 11 October 2019 (UTC)

Add mobileUndo gadget: discussions[edit]

According to mw:Reading/Web/Advanced mobile contributions, "August 8, 2019 ... Advanced mode is now available on all Wikipedias". When it will be deployed on Commons? 4nn1l2 (talk) 07:19, 11 October 2019 (UTC)

This literally happened yesterday for me on Wikimedia Commons while browsing 'This very page.
@4nn1l2:, it was rolled out to Wikimedia Commons, and had been available since yesterday. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:16, 11 October 2019 (UTC)
@4nn1l2: Yes, Advanced mode is currently available in all Wikimedia projects. The task is here. I've asked Johan (WMF) to announce it in the next Tech news. Masum Reza📞 15:26, 11 October 2019 (UTC)
  • Pictogram-voting-question.svg Question, I have a question, shouldn't this request better be filed in the Phabricator? As far as I can tell this is an uncontroversial change. There is no policy and/or guideline stating that mobile users shouldn't be able to undo edits using the "mobile view", in fact this is a mere technical restriction. Yes, it is still a proposal, but it's not like if someone would enable it today that it would be seen as controversial in any way. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:27, 11 October 2019 (UTC)
We don't have plans to make advanced mode default for everyone. But we'll transfer some of its features to all logged in users. Masum Reza📞 15:43, 11 October 2019 (UTC)
I Genuinely can't see the logic behind this, most users start editing Wikimedia projects / websites usually after first making edits without registering a Wikimedia SUL account, if we hide user-friendly features from novice users then they are less likely to become editors who could have been major editors to this (and other Wikimedia) website(s). I do not see how it serves anyone to give them "a dumbed down experience", especially for new markets like India where desktop users will be rarer. This policy is almost certainly one that will be a disadvantage for users from developing countries. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:14, 11 October 2019 (UTC)
I understand what you are saying but some editors prefer the old version mostly because of its simplicity. And some old mobile browsers don't even support JavaScript. There was 81% retention rate when AMC first had been deployed to 7 Wikipedias. This means that some still use the non-AMC mode. And 19% is still a big number. See some related discussions on Mediawiki - mw:Topic:V5fyhptg7yeuhi1s and mw:Topic:V64xirqg9ncsv7dh. Though I agree that IP editors should have access to this mode. OVasileva (WMF) is Reading web teams' product manager, and she makes all decision for this project. She might know more. If you have more questions, please don't hesitate to ask at mw:Talk:Reading/Web/Advanced mobile contributions. Thanks. Masum Reza📞 19:56, 11 October 2019 (UTC)
Thanks for the reply, I will look into it. Face-smile.svg --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:59, 11 October 2019 (UTC)

Show the FileExporter's "Export to Wikimedia Commons" button only to users on other wikis with certain rights[edit]

Per this post regarding FileExporter's "Export to Wikimedia Commons" button on other wikis and the resulting files here on Commons, Johanna Strodt (WMDE) wants to know if we approve of the subject (option 2 in her post). See also COM:VPT#FileExporter/FileImporter: Suggestions how to deal with files from wikis that have a higher amount of copyright violations.   — Jeff G. please ping or talk to me 12:26, 11 October 2019 (UTC)

Votes (Show the FileExporter's "Export to Wikimedia Commons" button only to users on other wikis with certain rights)[edit]

  • Symbol support vote.svg Support as proposer.   — Jeff G. please ping or talk to me 12:06, 12 October 2019 (UTC)
  • Symbol oppose vote.svg Nah File exporter automatically exports page history and all old versions of a file. If we show the button to only user with certain rights, others will find alternatives such as Commonshelper. And this will only raise the backlog of Bot move to Commons category. Files transferred using Commonshelper usually needs cleanup. And it doesn't even transfer old versions and page history which is required for attribution. File exporter automatically cleans up file pages, blocks files from transferring with unsupported license, detects abuse filter blocking, and it has many more feature that Commonshelper doesn't. Besides just because a user has few more rights doesn't necessarily mean that user has more experience. So suppose that a experienced editor (on Commons/or a wiki) wants to move files from another wiki (where they don't have the necessary rights) to Commons using file exporter. They wouldn't be able to use this feature and they would just use alternative methods as I've mentioned. We can not give out rights to every experienced user on every wikis. Also even if we hide that portlet link, it can be easily replicated using user scripts. And anyone can easily use this feature that way. Masum Reza📞 22:58, 12 October 2019 (UTC)
    @Masumrezarock100: what scripts?   — Jeff G. please ping or talk to me 07:14, 13 October 2019 (UTC)
    Seeing that FileImporter is optimized for mobile and there is no direct links to the FileImporter in mobile site, I've created a script for mobile which adds an Export to Wikimedia Commons button. Just import it in your minerva.js in English Wikipedia and navigate to a local file to see the demo. This means anyone can create a script to use the FileImporter. Masum Reza📞 15:53, 13 October 2019 (UTC)

Discussion (Show the FileExporter's "Export to Wikimedia Commons" button only to users on other wikis with certain rights)[edit]

  • @Jeff G.:, would it be possible to add multiple options for which user rights (if any) should be given this option? I personally would like to see every registered user be able to do this, unless they've abused the function. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:03, 11 October 2019 (UTC)
    @Donald Trung: I would hope so. An example "file exporter" user right could be held by members of a "File Exporters" group on (for example) Arabic Wikipedia, once the coding and infrastructure are in place. It might also make sense to have a corresponding "file importer" right and "File Importers" group here if importation gets out of hand.   — Jeff G. please ping or talk to me 12:05, 12 October 2019 (UTC)
    @Jeff G.:, that is a really good idea, especially if any user can then tag a file for transfer to Wikimedia Commons, but that then a "File exporter" with sufficient knowledge of copyright (and perhaps Wikimedia Commons categorisation, rules, and guidelines) will then actually decide if it is or isn't compatible with Wikimedia Commons. If this proposal asks for the creation of this specific right I would support it, otherwise it should be "an option on the ballot 🗳". --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:49, 12 October 2019 (UTC)
    @Donald Trung: Actually, given the vetting, knowledge, and experience of License Reviewers here, I think it would be fair to give them this right.   — Jeff G. please ping or talk to me 22:39, 12 October 2019 (UTC)

Make it easier for the Commons community to identify from which wiki FileExporter file transfers are coming using a template which applies maintenance categories[edit]

Per this post regarding FileExporter's "Export to Wikimedia Commons" button on other wikis and the resulting files here on Commons, Johanna Strodt (WMDE) wants to know if we approve of the subject (option 3 in her post). See also COM:VPT#FileExporter/FileImporter: Suggestions how to deal with files from wikis that have a higher amount of copyright violations.   — Jeff G. please ping or talk to me 12:27, 11 October 2019 (UTC)

Votes (Make it easier for the Commons community to identify from which wiki FileExporter file transfers are coming using a template which applies maintenance categories)[edit]

  • Symbol support vote.svg Strong support, this is really a must, if an image comes from an external (non-Wikimedia) website and it's in a language most people don't speak, then the people who can patrol these uploads should be given the tools to more easily find the files to be reviewed. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:05, 11 October 2019 (UTC)
  • Symbol support vote.svg Support as proposer.   — Jeff G. please ping or talk to me 12:06, 12 October 2019 (UTC)
  • Symbol support vote.svg Support -- (Talk/留言/토론/Discussion) 12:19, 12 October 2019 (UTC)
  • Symbol support vote.svg Support -Masum Reza📞 14:40, 12 October 2019 (UTC)
  • Symbol support vote.svg Support Would make it easier for Commons to patrol, and would make it easier for admins/interested users on other projects to help patrol transfers from "their" project. No real downside that I can see. --Xover (talk) 11:48, 13 October 2019 (UTC)

Discussion (Make it easier for the Commons community to identify from which wiki FileExporter file transfers are coming using a template which applies maintenance categories)[edit]

  • Pictogram voting comment.svg Comment, I would preferably see the imports organised like OrgeBots daily uploads by users with less than 250 (two-hundred-fifty) edits + (PLUS) these files being added to a larger more general maintenance category per non-Wikimedia Commons wiki. That way files could be patrolled more easily, if they would all be dumped into a single category that only allows us to see them alphabetically and not based on upload date then we won't be able to properly find new files. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:52, 12 October 2019 (UTC)
    @Donald Trung: We could have the template categorize by source wiki language, source project, and import date. Magog the Ogre would then have sufficient information for his bot to make reports.   — Jeff G. please ping or talk to me 07:12, 13 October 2019 (UTC)