Open main menu
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 aidEdit

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 toolsEdit

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: votesEdit

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

No image optimizer tools: discussionEdit

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

Template:Wrong sourceEdit

There is a Template:Wrong license, which is good, but I miss a Template:Wrong source. It seems as there are a lot of files where the users claim that it is "own work" where it clearly is not, such as certain logos etc. Can someone create a template which works exactly like Template:Wrong license, but with the source? Thanks!Jonteemil (talk) 04:43, 14 August 2019 (UTC)

In practice, in years gone by, people would just use the "no source" template for that purpose, although the creation of a "wrong source" would be good. You could probably just copy the wrong lincense template and make adjustments as needed. Killiondude (talk) 19:22, 15 August 2019 (UTC)
@Killiondude: Thanks for your answer. I wonder which template I should copy. Template:Wrong license which just says that it has the wrong license or Template:No source since which says that it has no source AND that it will be deleted in seven days unless sources are added. The graphics are also different. The first one is orange and the second is red with a clear ”THIS IS WRONG” vibe if you know what I mean.Jonteemil (talk) 21:16, 23 August 2019 (UTC)

Allow file movers to suppress redirectsEdit

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)

Category titles with scripts other than LatinEdit

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)
  • 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-WPstyleEdit

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)
I added bn (Bengali) translations. Masum Reza📞 15:20, 16 September 2019 (UTC)
  • Symbol support vote.svg Support And I added Persian translation. Ahmadtalk 15:31, 19 September 2019 (UTC)
  • And now, I am requesting for the legacy template to be renamed. Calvinkulit (talk) 03:50, 22 September 2019 (UTC)

The picture of the location of temperate rainforest File:Temperate rainforest map.svg have the mistake。 温带雨林地点图片有事实性错误Edit

The picture of the location of temperate rainforest Temperate rainforest map.svg (File:Temperate_rainforest_map.svg) have a mistake. The location of the temperate rainforest means most of this mostly in oceanic moist regions, and in the temperate zone. As a result, the location in P.R.China is not the temperate rainforest. The right picture (my evidence) is : DellaSala, D.A., 2011. Temperate and Boreal Rainforests of the World: Ecology and Conservation. Island Press

温带雨林地点图片有事实性错误。 (File:Temperate_rainforest_map.svg) 中国云南的那一块不是温带雨林。 证据(正确的图片)在:

DellaSala, D.A., 2011. Temperate and Boreal Rainforests of the World: Ecology and Conservation. Island Press
— Preceding unsigned comment added by Tangmingxyz (talk • contribs) 12:37, 9 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; 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 oldEdit

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)

Make Autopatrol automatically given once the user hits the 30/500 markEdit

As a user that just hit the 30/500 mark, I believe that Autopatrol should be automatically given when someone hits the 30/500 mark, much like how the same 30/500 rule gives the extendedconfirmed right in Wikipedia. Calvinkulit (talk) 09:13, 16 September 2019 (UTC)

  • Strong Symbol oppose vote.svg Oppose - Autopatrolled right isn't like the extended confirmed user right. Autopatrolled allows users to batch upload files upto 500. Only trusted should be given this right. Also it marked one's edits automatically patrolled, inexperienced users can seriously abuse this right. Masum Reza📞 09:26, 16 September 2019 (UTC)
(Edit conflict) Symbol oppose vote.svg Oppose Autopatrolled and extended confirmed is totally different. Extended confirm only gives the user an extra right which allows them to edit "extended confirmed protected" pages. The autopatrol flag should only be given if the user is fit/trusted for it such as recommendation by patrollers, etc. (Talk/留言/토론/Discussion) 09:28, 16 September 2019 (UTC)
  • However, I won't oppose if someone recreates the extendeduploader right. It may automatically be given to an user when they reach about 1000 uploads. IMO, upload by url isn't sensitive. Masum Reza📞 09:37, 16 September 2019 (UTC)
@Masumrezarock100: a proposal is in the works. (but waiting for technical details) - Alexis Jazz ping plz 13:39, 16 September 2019 (UTC)
Symbol oppose vote.svg Oppose Autopatrolled should not be given away by any automated process. I suppose we could create the extendedconfirmed group here, but we'd need a clear view of what we'd use that for. - Alexis Jazz ping plz 13:39, 16 September 2019 (UTC)
@Alexis Jazz: Possibly QIs, FPs & other images that have a usage of more than 5? (Talk/留言/토론/Discussion) 13:44, 16 September 2019 (UTC)
@大诺史: You mean protecting those so you need extendedconfirmed to edit/overwrite them? That's possible. Perhaps extendedconfirmed could also be given the increased move rate limit and be allowed to upload more than 50 files (but how many?) with UploadWizard. For upload_by_url I'm working on another proposal. Extendedconfirmed should probably not be allowed to bypass the abusefilter to upload Mp3 files. - Alexis Jazz ping plz 13:55, 16 September 2019 (UTC)
@Alexis Jazz: Maybe 100 or so? The upload wizard (for me) is pretty slow sometimes, so being able to upload more files at once does not neccessarily mean that it's a good thing for all. (Talk/留言/토론/Discussion) 14:00, 16 September 2019 (UTC)
@大诺史: Yeah, probably. Don't want to go too high as a proposal may be rejected for that. - Alexis Jazz ping plz 14:06, 16 September 2019 (UTC)
Maybe add Import offline translations (translate-import) rights to extendedconfirmed? This right is currently only available to Translation administrators. Note that there is an user group named "Offline translators" on translatewiki where this right is included. I do not think this right is much sensitive. It is very useful when translating. Masum Reza📞 14:07, 16 September 2019 (UTC)
  • Symbol oppose vote.svg Oppose No. It's about autopatrol, only trusted users can have it. Yes, some users show great talent, they are familiar with copyright rules etc. so they become autopatrolled once they are around 30/500; but it isn't true about all users. Such users may request for this right and they are very likely to get it, but making it automatic? No, this right is more sensitive than that; and extendedconfirmed isn't as sensitive as this (it's only useful when you want to edit an extendedconfirmed protected page). Ahmadtalk 18:51, 18 September 2019 (UTC)
No, not good at all.--Roy17 (talk) 15:51, 19 September 2019 (UTC)
  • Symbol oppose vote.svg Oppose: That's not a good idea because it's not edit-countable whether a user is trusted or not. One could consider giving an automated autopatrol status to users who are trusted users on other wm projects. --Achim (talk) 16:18, 20 September 2019 (UTC)
  • Symbol oppose vote.svg Oppose per the opposers above. Not a good idea.   — Jeff G. please ping or talk to me 16:50, 20 September 2019 (UTC)

Enable Flickr import (upload_by_url) for all usersEdit

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): votesEdit

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

Enable Flickr import (upload_by_url) for all users: discussionEdit

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)
  • @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)

Restrict move permission for root userpagesEdit

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

A DR noticeboard for language/country-specific issuesEdit

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