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

Shortcuts: 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.

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)
  • 不认同。同阿拉伯字母/希伯来字母/婆罗门系字母不同的是,汉字是语素文字,难以使用作为全音素文字的拉丁字母进行精确而可逆地转写。况且汉语族诸语言音系繁杂,基于何方言之音转写为是?显然以任何一门方音/标准音的拼音方案“转写”汉字都绝非好主意。--Snghrax(UTC) 11:44, 8 November 2019 (UTC)
  • Translation: Disagree. Unlike Arabic, Hebrew, and Brahmic scripts, Chinese characters are logograms. It is hard to transliterate them into Latin script, which is an alphabet, in a precise and reversible manner. Moreover, phonologies of different varieties of Chinese language are complicated, and which local/standard dialect should we adopt as the basis of Romanisation? Apparently, it is definitely not a good idea to Romanise Chinese based on any dialect standards. --Spring Roll Conan ( Talk · Contributions ) 12:31, 8 November 2019 (UTC)
  • Pictogram voting comment.svg Comment Surely an exception would be (say) Category:Russian letter Б and Category:Russian letter В, which are currently found at Category:Russian letter B and Category:Russian letter V, respecitvely. (!!) This seems completely ridiculous to me, and is currently (not) being discussed at Commons talk:Categories#Clarification about non-Latin alphabets. - dcljr (talk) 03:23, 10 October 2019 (UTC)
  • Symbol support vote.svg Support As I recall from discussion in the early days of Commons, there was supposed to be more of this sort of thing for categories where the majority of active contributors would be participating with non-Latin characters; the only proviso being that there should be redirects &/or transliteration hat-notes for the benefit of users participating on Latin-character only keyboards. -- Infrogmation of New Orleans (talk) 02:18, 8 November 2019 (UTC)
  • I have noticed a user who have moved Chinese categories to apparently machine translated categories[3]. It has made the book less easy to find in google for Chinese language users. Category:Sāncháo běi méng huì biān seems just ridiculous. There is no Chinese search using Pinyin, just like no English user search google using IPA. There are also mistakes. For example, Category:正統道藏, which contains text related to the Chinese Taoism, was translated to "Orthodox road". Forced translation are the contradictory to being international. --維基小霸王 (talk) 05:22, 8 November 2019 (UTC)
  • Symbol support vote.svg Support It may be not a good idea to use Mandarin Pīnyīn to rename the title which were written in Han Character and can be read in the whole East Asia. - I am Davidzdh. 10:30, 8 November 2019 (UTC)
  • Well, I also noticed JuTa's move of files and categories and found many problems in segmentation/translation or both. I reverted some by moving it into more appropriate titles as I think fit. Yet there are several thousands of files and categories suffered from the problem, and I quickly feel tired. I am not clear whether Pinyin or direct translation apply (some of us preferred Pinyin,) and it becomes a recent topic of debate between some of us. I think that it is acceptable to translate them for the sake of those people unfamiliar with non-Latin scripts, though categories in Chinese characters should retain as redirects. However, others have told me that by doing so, we will create new problems like disambiguation. --Spring Roll Conan ( Talk · Contributions ) 12:41, 8 November 2019 (UTC)
  • Symbol support vote.svg Support, I agree with 維基小霸王. (BTW, this discussion reminds me of the discussion of opening Pinyin Wikipedia. A Pinyin word may point to more than one Chinese character. For example, Wang (surname) and He(surname). Besides, it's difficult to type Pinyin.)--Rowingbohe♬(Talk/zhwiki) 10:46, 9 November 2019 (UTC)
  • Symbol support vote.svg Support with redirects, like from English to Chinese.--Jusjih (talk) 03:01, 10 November 2019 (UTC)
  • Symbol support vote.svg Support category name in English actually makes working with them very difficult and inconsistent.--Midleading (talk) 03:48, 10 November 2019 (UTC)
  • Symbol support vote.svg Support per 維基小霸王。—— Eric Liu留言百科用戶頁 12:59, 17 November 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)
  • Support El Grafo idea. Subpage per language means I am only notified when there is an edit on the language I am interested in, and nothing else. — regards, Revi 01:42, 1 November 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)

Isn't "Discussions" a bit too general? Since this proposal is focusing on "Deletion requests", I suggest something like "Commons:Deletion requests by language". Creating subpages using langcodes is a good idea in my opinion. Ahmadtalk 13:51, 24 October 2019 (UTC)
I'm still working on it, but User:Ahmad252/Deletion requests by language is an example of what it might look like. I can create a specific subpage for each language using my bot, but we need to discuss on titles first. Ahmadtalk 11:30, 25 October 2019 (UTC)
@Ahmad252: I made Commons:Discussions by language. A subpage is called Commons:Discussions by language/Boards/pl for example. I have to add the extra layer 'coz if the main page should be made translatable so my original idea would clash the the translation pages. I dont think we should mass create subpages. We can wait for discussions that need help emerge and let users create the subpages.--Roy17 (talk) 15:37, 27 October 2019 (UTC)
@Roy17: Good idea, But I've always been a bit worried about the crowdedness that might happen in the future. I think we'd better create a collapsable template for this page and limit the TOC to level 2 headings. This way, anyone will simply uncollapse the venue they want to check, and other languages won't distract them. We can set the collapsable template to auto-hide when there is no DR for the specified language.
And I think creating an editnotice would be a good idea. The editnotice (Template:Editnotices/Page/Commons:Discussions by language) can explain how users should create and transclude each venue on the main page. Ahmadtalk 15:52, 27 October 2019 (UTC)
@Roy17: I edited the /pl subpage in Special:Diff/372722393 and made it collapsible, just as an example of what that might look like in the future. Ahmadtalk 18:32, 31 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)
  • Symbol oppose vote.svg Oppose So we are untagging, just to name one person, Russavias pictures now. See for example Commons:Deletion requests/File:Jimmy Wales by Pricasso.jpg. Absolutely not.--Snaevar (talk) 12:56, 19 October 2019 (UTC)
  • Symbol oppose vote.svg Oppose proposal does not exclude automated uploads. Bots are needed for back logs.--BevinKacon (talk) 14:55, 19 October 2019 (UTC)
  • Symbol oppose vote.svg Oppose We had many cases when a trusted user became untrusted at some point and lack of independent verification of their uploads generates problems in such cases. Our content should be irrevokably free, not only till the uploader becomes ugly. Ankry (talk) 07:50, 31 October 2019 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose Especially old files need a review. 1) back in the days many people were either not aware of or chose to ignore the fact that not every image that pops up on a US-Govt website is automatically PD-USGov. Many pictures on the various NASA websites for example came from cooperations with ESA, which made them subject to copyright. 2) just because someone is a reviewer now doesn't mean they didn't mess up in their newbie days. --El Grafo (talk) 08:53, 31 October 2019 (UTC)
  • Support Kaldari (talk) 17:57, 8 November 2019 (UTC)
  • Symbol support vote.svg Support. In the overwhelming majority of cases trusted users upload trusted files. If we have reason to believe a specific file is bad, we can remove that one. It does happen - image copyright can be complex. This is the same with sources; if a respected museum says "this painting is public domain" or a US government agency says "we took this photo", in general we believe them. In rare exceptions that turns out wrong, and in that case we remove that one; we don't stop the principle of believing respected museums or agencies. --GRuban (talk) 18:15, 8 November 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)
  • @Snaevar: I don't even.. What do you mean? What does the Russavia/Jimmy Wales portrait thing have to do with anything? Also, this proposal doesn't overrule the Precautionary principle. If an admin would have committed copyfraud, PRP deletion could still happen. But that would have to be judged on a case-by-case basis. - Alexis Jazz ping plz 14:15, 19 October 2019 (UTC)
  • @BevinKacon: The proposal is restricted to sources with a site-wide license or license restrictions that can be checked without having the actual source available. The general style must also match. In what scenario would a (semi-) automated upload cause a problem? I'm willing to consider excluding them if there is a good reason. - Alexis Jazz ping plz 20:02, 21 October 2019 (UTC)
    No external source is perfect or is in line with Commons policies. I come across derivative works, accidental uploads and FOP problems which have falsely gone through automated license review such as Commons:Deletion requests/File:Smoke from a wildfire (44218945101).jpg. See long history of User talk:Panoramio upload bot. If the license review back log needs reducing, bots are needed, not this.--BevinKacon (talk) 14:50, 26 October 2019 (UTC)
    @BevinKacon: This isn't about the backlog or bots. This is about linkrot. Though going forward, bots would help to prevent this from happening in the first place, but that's useless for what already happened. This proposal does not override COM:PRP, COM:DW or COM:FOP. - Alexis Jazz ping plz 15:02, 26 October 2019 (UTC)
    I think it's a very lengthy set of requirements, when simple a discussion at COM:VP on each case would be enough.--BevinKacon (talk) 15:20, 26 October 2019 (UTC)
    @BevinKacon: There are many cases. COM:VP could easily be flooded, and it wouldn't solve anything because actually reviewing them is impossible because the source links died and we have no "uploaded by a trusted user" status atm. It is a somewhat lengthy set of requirements, but it does cover many cases without the need for discussing every single case. Just check all the boxes and you're done. Those cases that it doesn't cover could be discussed on COM:VP or COM:VPC. In case it wasn't clear: many files from external sources do not have a licensereview template. They are not in the LR queue. They exist in a limbo where they could be deleted if someone notices the linkrot. - Alexis Jazz ping plz 15:38, 26 October 2019 (UTC)
  • @BevinKacon, Ankry, El Grafo: It's easy to oppose, but do you have a solution? It is a simple fact that we already have tons of files from external sources without a license review, and many of those sources are no longer available. They are merely waiting for someone to notice that at which point they can be deleted. This is currently a slow process, but could very easily be accelerated greatly, I've accidentally done so myself not too long ago. (and undid myself when I noticed what was happening) This can lead to a massive loss of files. And many of those are quite obviously free, there is certainly no "significant doubt" which COM:PRP requires. And Ankry: you've seen COM:ANU#Varaine, right? This is already reality, and this proposal changes nothing about that. - Alexis Jazz ping plz 11:42, 31 October 2019 (UTC)
Let me say the above in a more frightening way: I'm not a admin, yet (with some effort) I have the potential power to delete hundreds of thousands of pictures for silly reasons. That's bad. And others undoubtedly have the same power. That's worse. - Alexis Jazz ping plz 11:47, 31 October 2019 (UTC)
I don't have a one-size-fits-all solution, because there is none. But there must be some middle ground between handling everything on a case by case basis as it has been don in the past and just grandfathering in everything uploaded by a certain group of people. All I've see here so far are vague statements like "lots of stuff has lost its source". Has anybody actually had a look at where that stuff came from? I've had several cases where the original source seemed lost, but a replacement could be found – typically because the collection the file came from changed their system and did not redirect their old URLs (example). The sensible approach would be a more strategic one, imho. Before giving up and implementing another COM:Grandfathered old files, there should be some effort to fix what's fixable. Step back, analyze the situation and take inventory: Which sites are actually completely gone, which ones have moved, which ones could be replaced easily (keep ID, just change parts of the URL), which ones need to be fixed manually (like in my example)? --El Grafo (talk) 14:52, 31 October 2019 (UTC)
@El Grafo: I'm terrified of naming any examples, because they'll be the first to be headed for the shredder, simply by mentioning them. There is a category with over 10000 files from a news agency. Some are still available, but many are not. If I remember correctly, they should still be available at a different URL but that new URL is a lot of work to find and sometimes may be impossible. Another category has nearly 1000 files, but many of them are in use for infoboxes as they are photos of Wikipedia-notable people. The source website has vanished, only a portion was archived and another portion actually has a license review. The rest is left in limbo. Our current rules don't even allow keeping them, there is no "handling everything on a case by case basis", they will just be deleted even if a hundred people vote keep. - Alexis Jazz ping plz 00:16, 1 November 2019 (UTC)
@Kaldari: What alternative would you suggest? I put it in for uploads that match all the other criteria but still shouldn't be trusted because the uploader is manipulative. For example, Varaine. - Alexis Jazz ping plz 00:52, 8 November 2019 (UTC)
@Alexis Jazz: Crap, I misread the proposal. I thought they were OR criteria, not AND. Vote changed to support. Kaldari (talk) 17:58, 8 November 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)
I think we have pretty much consensus here. There are no oppose. Should we close this one as accepted? I can not edit IA-protected pages. So I can not close it. Some advised that we should merge both TinEye and GoogleImages search mobile and desktop version. There are some gadgets on English Wikipedia that loads in mobile, and we can use their definitions as references. I do know if there is a way to target both mobile and desktop. @Perhelion: you are one of the interface admins I know. Any thoughts? Masum Reza📞 09:02, 27 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)
  • Symbol oppose vote.svg NO. What's the purpose of this? To increase the amount of files in the bot script backlog? I hate using CommonsHelper. Calvinkulittc 23:24, 24 October 2019 (UTC)

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

Regardless, it wouldn't work. FileImporter is available on Commons and unless you do something here to restrict imports from other wikis, it wouldn't work. As I've said the button can easily be replicated. I suppose they could restrict files from importing from some wikis. That would mean, the FI would have to check the source wiki every time an user tries to import a file, check their user groups on that particular wiki, and then block/allow from importing accordingly. Too many steps here to do IMO. Just hiding that button from public view would not work. And as I've said, people would find alternative methods. Though the proposal below makes sense and should be implemented asap. Masum Reza📞 12:19, 20 October 2019 (UTC)
@Masumrezarock100: It already checks for autoconfirmed (or local equivalent) on the source wiki.   — Jeff G. please ping or talk to me 12:32, 20 October 2019 (UTC)
@Jeff G.: Actually no. I do no have auto-confirmed rights on Arabic Wikipedia so I didn't see the "Export to Wikimedia Commons" button there but with my script I replicated the button. And guess what? I was able use to the import feature. For example, the Commons URL for importing this file from Arabic Wikipedia is this. And I could easily import it if I wanted (I didn't because the author field is missing). Care to guess what does this mean? This means that the Export to Wikimedia Commons button is only shown to auto-confirmed users on wikis. The FileImporter tool on Commons doesn't check for user rights on the source wiki. Only the button is hidden for non-autoconfirmed users. Any logged-in user can import files from other wikis even if they don't have auto-confirmed there. Masum Reza📞 17:55, 20 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)
  • Symbol support vote.svg Support, BUT on the condition that supporting this option 3 doesn't mean we completely rule out option 2. They don't exclude each other. @Johanna Strodt (WMDE): if we greenlight option 3, are you taking option 2 off the table? - Alexis Jazz ping plz 01:31, 18 October 2019 (UTC)
  • Symbol support vote.svg Support It will make it easier for patrollers who are familiar with languages other than English to patrol edits from other wikis, and can also help in backlogs. Ahmadtalk 12:51, 20 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)

Back up Google Ngrams[edit]

Google Ngrams.

You can do fun stuff with it, comparing word frequency like automobile vs car vs taxi and police car vs police automobile. And what's also really great about it: it's free!

Available under a Creative Commons Attribution 3.0 Unported License to be exact. But Google being a for-profit company, they have no obligation to host these files forever. They could be available for a long time, or gone tomorrow.

I'm not sure if this is strictly within our current scope. Educational, yes, totally, but COM:SCOPE isn't really clear about datasets like these. "representative merely of raw text, e.g. ASCII files" kind of suggests it falls outside of our current scope. But that line seems to have been written with text that should go into articles in mind, not gigabytes of tab separated data. Apparently we do have mw:Help:Tabular Data (I learned something today), but I'd also like to see the original files on Commons. (also I don't know if tabular data will even be suitable for this)

This will probably involve:

  • Declaring that at least for Google Ngrams, we are making an exception for COM:SCOPE.
  • Temporarily enable .gz uploads for either bots, administrators or a particular user who will upload it.
  • Add at least temporarily to wgCopyUploadsDomains.json for upload_by_url. - Alexis Jazz ping plz 03:43, 17 October 2019 (UTC)

Back up Google Ngrams: votes[edit]

  • Symbol support vote.svg Support - Alexis Jazz ping plz 03:29, 17 October 2019 (UTC)
  • Symbol support vote.svg Support.--Vulphere 13:36, 17 October 2019 (UTC)
  • Symbol support vote.svg Support - Commons has more useless(Ngrams are not useless BTW) files than these, why shouldn't we host these ? -- Eatcha (talk) 17:22, 17 October 2019 (UTC)
  • Symbol support vote.svg Support, these Ngrams seem very useful, though not all of these are equally useful, it's better to save them now then regret it tomorrow. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:30, 18 October 2019 (UTC)
  • Symbol support vote.svg Support - I'm sure people out there interested in this sort of thing will find these useful. –Davey2010Talk 20:56, 18 October 2019 (UTC)
  • Symbol support vote.svg Conditional support If this is generalised to "Allow dataset uploads with prior community agreement". Symbol oppose vote.svg Oppose If this is a Google-only exception. ℺ Gone Postal ( ) 04:37, 30 October 2019 (UTC)
  • Symbol oppose vote.svg Oppose - First off, these are mostly zipped and gzipped csv files. Shouldn't those go somewhere like CommonsArchive rather than here? Second, Google is more than capable of backing up their own files and generally gives a year or two notice before discontinuing any services. What's the point of creating a 2nd (3rd?) back-up on Commons when there is no reason to believe that Google is discontinuing Ngrams any time soon? Surely, there are more productive uses of our time and space. Kaldari (talk) 21:52, 7 November 2019 (UTC)

Back up Google Ngrams: discussion[edit]

@El Grafo: Doesn't even include the 2012 dataset. But why shouldn't Commons and both retain a copy? There is no technical or copyright reason why we couldn't. - Alexis Jazz ping plz 16:21, 17 October 2019 (UTC)
@Alexis Jazz: alright, but I think Commonsarchive would be a much better place for this. --El Grafo (talk) 16:17, 31 October 2019 (UTC)
We'd need to buff up its storage space significantly (a few order of magnitudes probably?) to store this. --Zhuyifei1999 (talk) 16:40, 31 October 2019 (UTC)
@Gone Postal: What's the difference? Prior community agreement will always be needed due to file formats. I guess you mean datasets should be added to COM:SCOPE? I agree with that, I'll create a proposal for that as well. Consider this proposal the finding of community agreement to upload Google Ngrams. - Alexis Jazz ping plz 15:36, 30 October 2019 (UTC)
@Alexis Jazz: Ok, fair enough. I just want to be sure that if I were to spend lots of resources and collect a good dataset about word useage on forums, newsgroups (yes, they still exist), etc, then they would be treated in a similar manner to Google's. ℺ Gone Postal ( ) 13:21, 31 October 2019 (UTC)

Give right to delete within first 24 hours of upload to the up-loader[edit]

This should decrease a lot of backlogs, why do I need to ask an admin to delete a file that is uploaded by mistake?


  • Symbol support vote.svg Support - What if you upload your private photos, wouldn't it be a good idea to delete that silently within seconds of upload, Instead of waiting for a sysop? -- Eatcha (talk) 05:31, 18 October 2019 (UTC)
  • {{S}} Won't help backlogs all that much, but I can't think of any severe downside. Should likely be done by a bot, not by MediaWiki feature request. (feature request could follow if the bot gets used extensively) - Alexis Jazz ping plz 16:03, 18 October 2019 (UTC)
  • Symbol oppose vote.svg Oppose, at least "for all users". I just realized there's a theoretical legal issue here. If someone were to upload material that the WMF isn't allowed to have on their servers, it could go unnoticed when deleted shortly after upload. I'm not talking about copyvios, I'm talking about the stuff that will send you straight to jail which the WMF scrubs from their servers as soon as it's detected. Perhaps deletion of own uploads within 24 hours could be acceptable for autopatrollers, but absolutely not everyone. - Alexis Jazz ping plz 06:53, 20 October 2019 (UTC)
  • Symbol support vote.svg Support I like the idea - hopefully technically feasible. Rudolphous (talk) 17:22, 18 October 2019 (UTC)
  • Symbol oppose vote.svg Oppose I'm not sure there is big backlog for such cases. Let's keep the delete tools for the approved users. IMO a marginal benefit. Christian Ferrer (talk) 18:48, 18 October 2019 (UTC)
  • Symbol oppose vote.svg Oppose No. There is not a backlog of these cases and you open an enormous can of worms when you take into account overwrites. If you have an image you want to delete and it is within the normal bounds of G7 tag it {{G7}}. It is literally that easy. If you need something deleted quicker because of personal information in it you didn't want, tell no one publicly and email oversight. This is a solution looking for a problem and will do nothing to actually help a nonexistant backlog. --Majora (talk) 20:43, 18 October 2019 (UTC)
  • Weak Symbol oppose vote.svg Oppose, I have often see some users nominate their own files for deletion because they don't want their image to be released under a free license despite irrevocably releasing it under one. While I certainly think that wrongly uploading something private is an issue, sysops can still view deleted files so it's not a mistake we can truly fix today. I am just afraid that this will enable too much deletion of otherwise high quality uploads at the whim of the uploader. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:45, 18 October 2019 (UTC)
    I do not think this is a problem. According to present rules, user can request deletion up to a week after upload without any explanation: this is a valid rationale for speedy and it is much longer period than the suggested 24 hours. Ankry (talk) 15:33, 31 October 2019 (UTC)
  • Symbol oppose vote.svg Oppose - My concern is that people will upload their files and then change their mind.... Licences are irrevocable but allowing this would provide a loophole meaning people could revoke the licence under "I uploaded it by mistake". –Davey2010Talk 20:48, 18 October 2019 (UTC)
    • We would generally respect a deletion request of "changed my mind" within 24 hours (or should). Very recent uploads are treated differently than ones that have been here for a long time. Carl Lindberg (talk) 20:55, 18 October 2019 (UTC)
      • I agree they are and I've endorsed deletion on a few of those .... however we've always gone by once the file is uploaded it cannot and will not be deleted, Not all uploader requests have been fulfilled, Reading the comments below I don't know if it is legally binding but I've always assumed it is. –Davey2010Talk 09:16, 19 October 2019 (UTC)
        • The speedy deletion guideline is to allow seven days. If someone made a mistake in the file they intended to license, let them fix it. But just not sure it's possible to give a full deletion right in that situation, so the current speedy process may have to be enough. Carl Lindberg (talk) 20:25, 19 October 2019 (UTC)
  • Symbol oppose vote.svg Oppose as it's unnecessary IMO. Such speedy/deletion requests are usually processed rapidly, if legitimate, as they don't require any discussion. Commons:Deletion requests/File:SharafkhanehPort00007.jpg was an exception, resulting from misunderstandings; I've deleted the image now. A problem is that we have contributors who, despite being active since years, think to have a right to delete their uploads, which had been on Commons for years, simply because they "want to". --Túrelio (talk) 09:25, 19 October 2019 (UTC)
  • Symbol oppose vote.svg Oppose I have requested speedy deletion for many thousands of deletions of my own uploads, which includes most often not using the standard speedy process/template and for files which may well have been hosted for much longer than a day. If anything we need to advise people a bit more openly on how courtesy deletions work, and perhaps spell out example scenarios in guidelines so that administrators make those choices more consistently and fairly. -- (talk) 09:31, 19 October 2019 (UTC)


  • @Eatcha: - None of these proposals are currently technically possible. The ability to delete pages is granted across the board by the delete flag. (See also Special:ListGroupRights.) There is no technical method of granting the ability to delete only certain pages or pages within a certain time frame, and this would have to be implemented from scratch. It is unlikely to be implemented even if we had a local consensus for it. If it somehow were implemented, the difficulty in doing so would almost certainly outweigh the marginal benefit. GMGtalk 15:22, 18 October 2019 (UTC)
User:GreenMeansGo It is possible, use an administrative bot, call that bot using a template to delete the file. What do you think ? --Eatcha (talk) 15:36, 18 October 2019 (UTC)
There is m:Synchbot to delete user pages, so I suppose this should be possible as well. - Alexis Jazz ping plz 16:03, 18 October 2019 (UTC)
Yeah. That's doable. At the same time, Synchbot was created to implement a global software change already implemented by the Foundation. I'm not sure you're going to get a local admin bot approved for a comparatively small qualify of life change, that's probably only going to be rarely used anyway. GMGtalk 16:15, 18 October 2019 (UTC)
Syncbot can delete user pages because it's operator has the "global deleter" right. Syncbot account doesn't do anything. Pathoschild is the one who deletes and edits userpages across Wikimedia projects. Masum Reza📞 18:22, 18 October 2019 (UTC)
@GreenMeansGo: such a bot could actually simply handle G7 taggings for recently uploaded files, so one doesn't need to be aware of the existence of the bot. In addition it could check deletion requests to see if someone nominated their own file, and consider those as G7 requests as well. - Alexis Jazz ping plz 20:00, 18 October 2019 (UTC)
G7 is for the unused content, and though I don't see me either why Ellin said it is 4 year old, a DR is fully appropriate for the content that is in use. We need approved users for the "delete" tool, we need users that are supposed to be familiar with our policies for this kind of tools. Christian Ferrer (talk) 20:39, 18 October 2019 (UTC)
Furthermore, it is not because a speedy tag is possible that the administrators have to delete it inevitably, if they thing that there is a good reason to keep the file, or to discuss about the deletion. Christian Ferrer (talk) 20:43, 18 October 2019 (UTC)
I think the cases where an uploader requests deletion of an unused file within 24 hours that shouldn't be deleted are really quite sparse. Oh, and that file was unused both when the DR was started and when I tagged the file for G7. It only became used after that. We can't allow random editors to sabotage G7 requests like that. - Alexis Jazz ping plz 22:37, 18 October 2019 (UTC)
  • @Majora: I agree this shouldn't be done to help with any backlog. I also agree a bot should ignore files that were overwritten, or even ones that are linked from other files. But tagging {{G7}} is not "that easy". You have to know about that. (which newbies never do) What about a bot that checks DRs and appends G7 where appropriate? - Alexis Jazz ping plz 01:07, 19 October 2019 (UTC)
    I'd be much more amenable to that. When I'm closing old DRs I take into consideration if the {{Delete}} tag was applied during the normal seven day window. If the file is not in use I almost always courtesy delete the file such as this example. A bot to do that tagging I would probably support. --Majora (talk) 01:12, 19 October 2019 (UTC)
  • @Donald Trung, Davey2010: I think legally the Creative Commons license may not be enforceable if someone changes their mind within 24 hours. At least on Commons. We don't ask uploaders to sign anything, we don't ask for confirmation. It is possible to upload the wrong file by accident, or upload a file without realizing you're releasing it under a free license, or what a free license even means. This could vary from country to country, probably even from judge to judge. But a contract is generally not valid unless all parties can be reasonably assumed to have understood its terms. - Alexis Jazz ping plz 01:07, 19 October 2019 (UTC)
    No, it is enforceable per CC FAQ. CC licenses are irrevocable. "I changed my mind" doesn't work here. Masum Reza📞 01:27, 19 October 2019 (UTC)
    @Masumrezarock100: CC license may not yet be valid at that point. This is no case of revoking a CC license (which, indeed, is not possible) but a case of the CC license having never been valid to begin with. The UploadWizard doesn't inform uploaders sufficiently and confirm they understood the terms sufficiently to be able to instantly turn an upload into a binding contract. This will vary from country to country. - Alexis Jazz ping plz 02:38, 19 October 2019 (UTC)
    Tell that to the Terms & Conditions that accompany all apps, websites, etc. that nobody reads or understands but are definitely legally binding. Ignorance of the legal ramifications of what you are doing does not indemnify you to those consequences. --Majora (talk) 02:52, 19 October 2019 (UTC)
    Is there no difference between those for profit companies and us. If no, why are we here ? Instead of volunteering for Apple or Ford. WMF must not become one of those companies. I'm asking for a single day, not even a week. -- Eatcha (talk) 03:09, 19 October 2019 (UTC)
    @Majora: Actually it can in some cases. At least in the EU. In the US Terms & Conditions are not always enforceable either. And in the UploadWizard, we don't even have a button that says "I release this work under a free license" or even "I accept", no.. we have "Next", which is legally nonsense. - Alexis Jazz ping plz 03:30, 19 October 2019 (UTC)
    I was thinking of the "clickwrap" types which the US link you mentioned pretty much states are legally enforceable. While I am not a lawyer and therefore this is not legal advice, the UploadWizard has a notification that you are releasing it under <insert license here> with a link to the full legal code. You have to acknowledge that you are agreeing to this action by clicking the "Next" button (which by the way is stored at MediaWiki:Mwe-upwiz-next and therefore could always be changed). Not as good as "I agree" but I would imagine these would fall under a clickwrap type scenario if someone would really decide to sue someone else over a reuse of a CC release image that they had deleted 12 hours later. --Majora (talk) 03:45, 19 October 2019 (UTC)
    @Majora: That, and there is one more difference. Terms & Conditions usually contain ordinary stuff. "We use Google statistics, we store cookies on your computer, underwear can not be returned if the packaging has been opened, you give us a non-exclusive license to use photos you upload, if anything bad happens we are not responsible for nothing" A user can expect such terms, they are generally reasonable. "You will release your work to the general public under an irrevokable free license" is not expected and quite possibly (from a legal point of view) not reasonable. (but I am also not a lawyer) The EU is probably more restrictive in this than the US. - Alexis Jazz ping plz 04:19, 19 October 2019 (UTC)

I already requested an edit filter to related to this backlog, Commons_talk:Abuse_filter/Archive_2018#Block_deletion_requests, but was rejected on technical basis.--BevinKacon (talk) 09:37, 19 October 2019 (UTC)

  • Pictogram voting comment.svg Comment Furthermore this kind of thing, in the case that it is technically possible, will potentially lead to a few other problems, e.g. some prolofic uploaders may be involved in conflicts with other members of the community and so then decides within an emotional "diva-like" behavior to delete all the upload they did in the past week. That is simply inacceptable as one of the pillars of the Wikimedia projetcs is that we don't really own the content that we add. The current situation at the discretion of the administrators, and in cases a little more complicated with formal DRs is quite good IMO. Christian Ferrer (talk) 17:06, 19 October 2019 (UTC)
@Christian Ferrer: one week is much longer than 24 hours, isn't it? - Alexis Jazz ping plz 19:21, 19 October 2019 (UTC)
Yes indeed, but the principle stay the same. Christian Ferrer (talk) 19:29, 19 October 2019 (UTC)
True, but impact of 24 hours is quite small. Regardless, I've changed my vote to oppose, albeit for different reasons. - Alexis Jazz ping plz 07:05, 20 October 2019 (UTC)

Adding the Wikidata Infobox to Taxon categories[edit]

Hi all. I would like to propose bot-adding {{Wikidata Infobox}} to taxon categories. Pi bot does not currently do this due to a mid-2018 discussion with WikiProject Tree of Life (during the early roll-out of the infobox) that indicated that the taxon-specific templates did a better job at the time, and there were possible differences between the Commons and Wikidata taxon structure. Since then, the taxon content in the infobox has been significantly improved, particularly thanks to @Christian Ferrer's input, and I haven't seen any examples of differences between the structures here and on Wikidata. The infobox is actually already used for around 40,000 taxon categories (due to early bot edits and later manual additions), so please see Category:Uses of Wikidata Infobox for taxons for examples of the live infobox for taxons.

We had a brief Village Pump discussion about this in August 2019, but it didn't get very far, hence this proposal to try to move things forward. If this is proposal is accepted, then it would take Pi bot a few days to deploy the infobox to the ~200,000 taxon categories that would be affected - I only have to remove the exceptions from the code and then let it run as normal. Issues/impromevents can be discussed at any time at Template talk:Wikidata Infobox as usual. After the deployment, duplicated content provided by other templates can be removed, such as {{VN}} (as it's auto-included in the infobox), and authority control information like {{IOC}}, {{IUCN}}, etc. that is provided by the infobox, and even {{Wikispecies}} links as they are built into the infobox. {{Taxonavigation}} and {{Subspecies}} would probably be the last to tackle, as they are the most complex and it's important to avoid losing information.

Pinging people involved in previous discussions about this: @Josve05a, Rudolphous, Thiotrix, Liné1, Christian Ferrer, Pigsonthewing, RexxS, ديفيد عادل وهبة خليل 2:. Thanks. Mike Peel (talk) 14:01, 19 October 2019 (UTC)

  • I am fully in favor of its implementation as suggested. I, myself, use it each time that I create a new taxon category. Christian Ferrer (talk) 14:15, 19 October 2019 (UTC)
  • Symbol support vote.svg Support "Wikidata Infobox" only ديفيد عادل وهبة خليل 2 (talk) 16:01, 19 October 2019 (UTC)
  • Symbol support vote.svg Support per ديفيد عادل وهبة خليل 2. Rudolphous (talk) 16:46, 19 October 2019 (UTC)
  • Symbol support vote.svg Support in general, though I'd like to see how the infobox handles subjects with vernacular names in many languages, such as Tyto alba. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:32, 19 October 2019 (UTC) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:32, 19 October 2019 (UTC)
    • @Pigsonthewing: I've added it to Category:Tyto alba, without removing any of the duplicated content, so you can see how it would look in this particular case. Thanks. Mike Peel (talk) 08:14, 20 October 2019 (UTC)
      • That produces much less clutter on the page than the current template, so I'm happy with that, Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:51, 20 October 2019 (UTC)
  • Symbol oppose vote.svg Oppose This should remain an opt-in. Categories are not articles, and the display of large infoboxes increasingly moves Commons to appearing like Wikipedia. The purpose of categories is to conveniently display media and sub categories against a topic, not to inherit lots of info suitable for Wikipedia articles about the topic for folks to read; we can link to the related Wikipedia article for that. -- (talk) 09:36, 20 October 2019 (UTC)
    • @: The Template and its divisions are showable and concealable ديفيد عادل وهبة خليل 2 (talk) 13:25, 20 October 2019 (UTC)
      • They should still be an opt-in to display. Most users will have to manually hide each one they come across in every single category if they don't want to see them (which is how it is currently set up), and this sort of real-estate eating display of optional information should always default to being an opt-in by design. -- (talk) 13:34, 20 October 2019 (UTC)
        • @: Other templates fill the page and cannot be folded ديفيد عادل وهبة خليل 2 (talk) 14:13, 20 October 2019 (UTC)
          • Sure, other templates are problematic too. Eating up the screen real estate of category pages is bad design, regardless of whether this is "improving" the interface with more options that users never actually asked for, or creating chunky templates and warning notices that will probably ever only be informative for a small minority of readers of the category, and probably only the very first time they view that category. Making Commons "smarter", is in fact making it increasingly unwelcoming for new users and long term users. -- (talk) 19:00, 1 November 2019 (UTC)
            • @: The media files are reason why the categories exist, so it's definitely important to maximise their screen real estate. After that, I'd say that context is the next most important thing, which is what the infobox tries to provide as multilingually as possible (imagine browsing Commons without knowing English). It's deliberately narrow and down the side of the page, so that it takes up the minimum amount of space above the page-fold/scroll, and most of its content is automatically hidden on mobile. While it needs to be shown by default so that readers can see it, there are instructions at Template:Wikidata Infobox for how registered users can auto-hide part or all of the infobox, or even to never to display it. If you want to maximise screen real estate for images, while also providing context/information about the topic, then I think that only using the infobox is the best way to do that. Thanks. Mike Peel (talk) 18:23, 2 November 2019 (UTC)
  • Symbol support vote.svg Support I find our own templates quite obscure and annoying to use (especially {{Taxonavigation}}) – and they don't even look good (especially {{VN}} on pages like Category:Tyto alba). --El Grafo (talk) 07:31, 22 October 2019 (UTC)
  • Symbol support vote.svg Support Even though I don't know much about species, {{VN}} on Category:Tyto alba looks really miserable, so I say good riddance to that.. - Alexis Jazz ping plz 20:39, 22 October 2019 (UTC)
  • Symbol support vote.svg Support This will help unclutter the pages and the code, and avoid some mistakes. But I hope Taxonavigation templates won't be removed until the Wikidata Infobox properly displays taxon authorship. --LamBoet (talk) 18:05, 23 October 2019 (UTC)
  • Symbol oppose vote.svg Oppose Template {{Taxonavigation}} has important features for categorization: it automatically adds categories, e.g. Category:Species of Tytonidae, Category:Genera of Aves. The special taxonavigation templates for {{Coleoptera}} and {{Lepidoptera}} even do the primary categorization (species into genus categories and so on). Thousands of categories would be completely uncategorized, if the taxonavigation templates should be removed. Do not delete {{Taxonavigation}} automatically, unless all author citations have been imported into Wikidata and categorization problems are solved. – Regarding the vernacular names section, I admit, that it is rather full on Category:Tyto alba and does not look good, because long VN sections are not collapsible yet. But the awfully formatted VN section in the Wikidata Infobox is not even readable! I prefer to keep our horizontal VN at the top of each taxon category, if possible in a foldable format which hides foreign languages. Additionally, the long section of partly unrelevant databases clutters the Wikidata infobox, and this part will grow constantly with every new database that is included into Wikidata. (On the contrary, really relevant databases like AlgaeBase are still missing at Wikidata, as their data structure seems to be difficult for automatic input). --Thiotrix (talk) 08:47, 24 October 2019 (UTC)
    @Thiotrix: In cases where the taxonavigation template (or any of the others) is adding categories or showing info that isn't in the infobox, I'd agree it shouldn't be removed until it is in the infobox, and that should be part of the migration. I've tweaked the formatting of VN, so it may look a bit better in the infobox now, and we can continue iterating on that. Databases aren't included automatically, the infobox contains a list of which ones to show, and that can be tweaked if needed. Thanks. Mike Peel (talk) 15:53, 28 October 2019 (UTC)
  • Symbol support vote.svg Support Seems like a good idea, and well-tested so far. --SJ+ 14:12, 26 October 2019 (UTC)
  • Weak oppose Neutral - Much of the higher-level taxonomy (above genus) on Wikidata is outdated due to circular referencing from various Wikipedias. I would like to see this improved before we start using it. Kaldari (talk) 18:54, 1 November 2019 (UTC)
    • @Kaldari: If this is true (Not doubting you personally - I don't know enough about high-level taxonomy to say one way or the other!), then the information on Wikidata needs to be updated. I think that the best way to do this would still be to add the infoboxes to the categories - then people can spot discrepancies and then fix them on Wikidata. If the information isn't shown, then it won't get fixed. Thanks. Mike Peel (talk) 18:50, 2 November 2019 (UTC)
      • @Mike Peel: That's a decent point. I'm still not much of a fan of infoboxes in general, so I'll put myself as neutral. Kaldari (talk) 01:27, 3 November 2019 (UTC)
  • Symbol support vote.svg Support per Mike Peel, if the info is not shown how can we fix it. I personally don't look for errors on Wikidata, but if displayed in a human-friendly way I am up for that. -- Eatcha (talk) 03:07, 3 November 2019 (UTC)
  • Symbol support vote.svg Support per Mike Peel. I use "Wikidata infobox" for any new category I create. - Ambrosia10 (talk) 04:31, 5 November 2019 (UTC)
  • Symbol support vote.svg Support -- Rodrigo Tetsuo Argenton m 17:11, 8 November 2019 (UTC)
  • Symbol oppose vote.svg Oppose, very strongly - it duplicates information better presented in the taxon templates, and above all, because it is vertical, it completely buggers up the arrangement of the images below (on my monitor, a very useful 10 images per row, but not where the wikidata box shoves them around). The wikidata box also comes with a whole plethora of external site links that are not particularly relevant nor useful being duplicated at Commons; they belong at wikidata and should be left there. I'd be less strongly opposed if the wikidata box were made horizontal to stop it running over pics in the category, and didn't include all the ext links or superflously duplicate an image from the category. If this does go ahead, please make the default state for the wikidata box to be hidden, not shown, and/or make default hiding it an option one can tick in ones' preferences. - MPF (talk) 18:56, 12 November 2019 (UTC)
@MPF: I'm guessing you're lucky enough to have a big computer monitor? On my 13" laptop, Category:Tyto alba doesn't show *any* pictures from the category until I scroll down, the whole screen is taken up by the taxon navigation text. (It was even worse with this version as the first image was then on the 4th page down!) Having the infobox on the right means that you immediately start seeing the category pictures, and you should only lose 1-2 columns at the start of the category (if it's displaying differently than this, please share screenshots so I can debug it). There are various user options described at Template:Wikidata Infobox that you can try to change the infobox's dimensions - in particular, there's a horizontal option, although it only works in some browsers. The external links have been added either because they are already used in taxon categories (taking up even more vertical space), or because they've been requested to be shown - but we can try to reduce these if needed (and you can auto-hide them with a user option if you want). Hiding the infobox by default would be bad for readers/new users, so I don't want to do that, but moving the user options into the preferences/gadgets is a good idea. Thanks. Mike Peel (talk) 06:06, 15 November 2019 (UTC)
"external site links that are not particularly relevant": have links to external sources and taxonomic databases is desired, used, added by almost everyone who is interested in taxonomy. GBIF itself use the external identifiers for taxa that are stored in Wikidata (see at bottom), as well as Wikipedia(s), and Wikispecies (who has something similar in the principle) would likely do it too if someone had brought the tool to do it. Christian Ferrer (talk) 07:46, 17 November 2019 (UTC)

Adding the Wikidata Infobox to Taxon categories: discussion[edit]

  • I'm not going to oppose this, probably not support it either because I don't do much in that field and I don't know if it's a good replacement. The only taxobox I ever made was literally just a joke. It sounds sensible though. But on a more general note, Mike Peel, it might be a good idea to apply it to a few hundred categories first and see if any problems or missing features pop up that could be fixed before deploying to all 200,000 categories? - Alexis Jazz ping plz 07:55, 20 October 2019 (UTC)
    • @Alexis Jazz: It's already in use in ~40,000 taxon categories, see Category:Uses of Wikidata Infobox for taxons, and I think they should be fairly representative so I don't think a further trial is needed. Problems can always be fixed later as the infobox will automatically update in the categories without further edits. Thanks. Mike Peel (talk) 08:09, 20 October 2019 (UTC)
      • @Mike Peel: Okay, that should be enough. Maybe provide some "before" and "after" links to show less knowledgeable users what will change? - Alexis Jazz ping plz 18:19, 20 October 2019 (UTC)
  • Getting taxonomy via Wikidata is going to produce some funky results. If the Wikidata Infobox is used on Category:Tyrannosaurus, it displays (in part):

Class Reptilia
Order Dinosauria
Order Saurischia
Suborder Theropoda
Order Avetheropoda
Suborder Coelurosauria

No kingdom or phylum are shown for Tyrannosaurus. Fossil taxa in general are likely to have a weird taxonomic hierarchy at Wikidata, especially when they are members of a group that is paraphyletic. Using Wikidata to produce an infobox for any vascular plants omits the clades recognized by APG that are currently shown in Taxonavigation. 20:18, 13 November 2019 (UTC)

@anon Please see my reply above to Kaldari. The best solution here would be to improve things on Wikidata, and I think showing the information here would help that happen, rather than these issues not being visible. Thanks. Mike Peel (talk) 06:09, 15 November 2019 (UTC)

Offer 'File Filter and Sort' features not offered by Special Pages, Templates, and API[edit]

I would like to create a Filter and Sort WikiMedia Commons Files website that offers features that are not currently offered by Special Pages, Templates, or the WikiMedia Commons API.

In addition to Filtering by all available fields, this website will also Sort by all available fields, including the following:

  • Uploaded Date
  • File Size
  • Page Views
  • Downloads

To accomplish this, the website will cache the data so it can be filtered and sorted by any field.

Here are two examples of features that I could not find in WikiMedia Commons, which this website will offer:

  • Display the most recently uploaded Midi files.
  • Show files in order of their File Size, PageViews, or Downloads.

Wikimedia Commons has pages that offer some of these features, but you can't combine the filter and sort. For example, this page lists all 'audio/midi' files, but you can't see the most recently uploaded files:

This page indicates that searching by Mime Type (aimime) is "Disabled due to miser mode". Therefore, using the current API, you can't search for 'audio/midi' files (I don't know how the **MIMESearch** page does it):

Please confirm that I can create a WikiMedia Commons page which describes the Filter and Sort WikiMedia Commons Files website, and that I can display this page in the "Pages in category" section of all WikiMedia Commons pages that list files.

This proposed website will contain no advertising or subscription fees. ToolCreator (talk) 21:28, 22 October 2019 (UTC)

Sounds like a good plan to me. The current Mediawiki sorting system is not good at all IMO. @ToolCreator: There is no need to create and manage a separate domain/website. Wikimedia Toolforge would like to host such tools. Please see toollabs: and wikitech:Nova_Resource:Tools/Getting_started. Thanks. Masum Reza📞 22:48, 22 October 2019 (UTC)
@Masumrezarock100: Thank you for your suggestion. Unfortunately, Toolforge has strict limitations upon the usage of cron, which would be required to create this application. Without those limitations, a poorly created Toolforge application could bring the entire system down. For that reason, a dedicated server is usually required for unlimited cron usage. For more information about this issue, search Google for "toolforge cron".
That is probably why no one has yet created the application that I described, even though there should be a huge demand for the ability to sort the files.
I understand your concern. However, please note that this application would be read-only, so there is no risk of negative effects upon your data. ToolCreator (talk) 23:14, 22 October 2019 (UTC)
Regarding toolforge, you should submit a job to grid engine which avoids much of the limitations of bare cron. Wikimedia Cloud VPS also exist.
If you do decide to host it externally, please note that some of us (me included) may be somewhat hostile to it.
By the way, do you realize Special:Search is awesome? --Zhuyifei1999 (talk) 23:31, 22 October 2019 (UTC)
Regarding Special Search: Where is the "filemime" parameter documented? Also, the only sorts offered are Relevance and Date. My website would allow you to sort by any field; including File Size, Page Views, and Downloads.
Regarding the cloud server: There are always more limitations upon a cloud server, than on a dedicated server. For that reason, I would not want to incur that inconvenience, for a read-only website that does not require any additional permissions. That's why I pay thousands of dollars a year for a dedicated server.
I could have this website up in 1-2 weeks. If you can find someone else to create it on your cloud server, then go for it. Otherwise, I would need to know that you would not be hostile towards it. Your users would need to know that it exists. ToolCreator (talk) 23:53, 22 October 2019 (UTC)
I found the answer to my 'filemime' question. This page lists the four file properties that you can search for: ToolCreator (talk) 23:59, 22 October 2019 (UTC)
Also, thank you for the information that you provided. I did not know about that Special Search page, which is very useful. I also did not know that WikiMedia offers usage of their cloud server for free, which I will definitely look into. I guess there is no reason for anyone to pay Amazon! ToolCreator (talk) 00:17, 23 October 2019 (UTC)

Drop the Help:Watchlist messages // Gadget-WatchlistNotice[edit]

While WatchlistNotice has been used fairly actively until 2018 there were only 4 in 2019 and it's plenty of legacy code, including the now deprecated jquery.ui. As the system's importance is ceasing, I suggest de-registering the gadget, reverting the MediaWiki pages that transclude the messages into the Watchlist and the Community portals so the system doesn't bind JavaScript maintainer's resources. -- Rillke(q?) 23:07, 26 October 2019 (UTC)

@Rillke: What's the downside/what will break? - Alexis Jazz ping plz 23:09, 26 October 2019 (UTC)
Well, I suggest to drop the possibility to broadcast messages through watchlist messages as described in Help:Watchlist messages. I expect nothing else to break. If itsn't dropped it probably won't break tomorrow, however a lot of this site's code needs a major overhaul and reducing features helps to focus. -- Rillke(q?) 23:28, 26 October 2019 (UTC)
@Rillke: We still have the sitewide banner thingy, right? - Alexis Jazz ping plz 15:40, 30 October 2019 (UTC)
Yes, you will still have the site notice. Watchlist notice was introduced to have a more fine-grained, compact messaging system capable of handling many messages without becoming too annoying. However, as it isn't used, it fails its purpose. -- Rillke(q?) 21:40, 30 October 2019 (UTC)
Symbol support vote.svg Support Having a second notice system that works differently than the main one is quite confusing anyway. Sebari – aka Srittau (talk) 16:25, 30 October 2019 (UTC)
  • Symbol support vote.svg Support One notice system seems enough. - Alexis Jazz ping plz 21:46, 30 October 2019 (UTC)

Module categorization[edit]

is currently done only with the related documentation. When no docu is generated, the module remains uncategorized - and can be encountered just accidently. Sandboxes of modules (and all modules containing a subname after a slash) cannot get a documentation, it's only possible for the main name. This situation is not at least satisfying. I suggest as a remedy the following:

The latter one may serve somehow also as a maintenance category – but at least it will contain all the modules not visible in the other categories. This will make easier the navigation in that namespace. -- sarang사랑 08:39, 27 October 2019 (UTC)

I like the sandbox categorization idea, we have the same thing in template sandboxes. Combining it with SQL, this can also be useful to detect and delete old module sandboxes (though I don't recommend it because creating a sandbox version for a module with several submodules can sometimes take some time). I'm not sure about tagging every single uncategorized module with a maintenance category. Besides the technical challanges (I personally can't find a way to implement it), do we really need to categorise all modules? In some cases, it can be very useful, but we don't even categorise all templates. Nonetheless, you can always create a module /doc subpage and only include some categories in it. Ahmadtalk 16:56, 30 October 2019 (UTC)

Namespace redirect UT: for User talk[edit]

Not case-sensitive. (UT: or ut: would both work) Ahmadtalk 16:17, 27 October 2019 (UTC)

  • Symbol support vote.svg Support Ahmadtalk 16:17, 27 October 2019 (UTC)
  • Symbol oppose vote.svg Oppose Normally, users should not visit (or even watch) other users' talk pages, because it most probably causes drama. No need to facilitate this. 4nn1l2 (talk) 16:23, 27 October 2019 (UTC)
    @4nn1l2: Yes, but someone who wants to visit someone else's talk page will most probably check it, whether with UT or without it. I think this can be useful mostly when you are busy doing something and you want to request help, ask questions etc from someone you know. I mean, can this, solely, become a problem (or at least, a somehow important part of the process that creates the problem)? Ahmadtalk 19:41, 27 October 2019 (UTC)
  • GA candidate.svg Weak support UT isn't a valid 639-1 code currently, but it still might cause some confusion as two-letter codes usually go to Wikipedia, like de:Wikipedia and jp:ウィキペディア. - Alexis Jazz ping plz 00:58, 28 October 2019 (UTC)
  • Symbol support vote.svg Support -- Eatcha (talk) 03:54, 28 October 2019 (UTC)
  • Symbol support vote.svg Support, I can see how this is good for searching, probably less useful for linking itself, I can't see how this hurts and it's better to have something than need it and not have it. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 05:01, 28 October 2019 (UTC)
  • Symbol support vote.svg Support useful. -- (Talk/留言/토론/Discussion) 02:51, 30 October 2019 (UTC)
  • Symbol support vote.svg Support. –Davey2010Talk 11:01, 30 October 2019 (UTC)
  • Symbol oppose vote.svg Oppose per Alexis, due to confusion - two-letter codes are usually interwiki links. ~riley (talk) 05:12, 31 October 2019 (UTC)
    Yes, but for what language? I mean, is there a (somehow) strong possibility of confusion? Ahmadtalk 10:02, 31 October 2019 (UTC)
    If a new language code appears, we may have problem. It is wise to avoid them. Ankry (talk) 15:35, 31 October 2019 (UTC)
    In that case, maybe something like UTP could be a better idea. Ahmadtalk 18:35, 31 October 2019 (UTC)
    Now I'm thinking about network cable. - Alexis Jazz ping plz 08:28, 3 November 2019 (UTC)
    Maybe we should just forget about it, I can't think of any better alias. Ahmadtalk 17:41, 3 November 2019 (UTC)
    @Ahmad252: I splitted this off to allow more votes to come in. If the next two votes support, UT: can be requested. If the next two oppose, there's no consensus. - Alexis Jazz ping plz 07:42, 5 November 2019 (UTC)
    Good idea. We'll have a clear consensus then, and we will hopefully discuss on downsides more. Ahmadtalk 11:54, 5 November 2019 (UTC)
  • Symbol oppose vote.svg Oppose per Jarekt below. Multichill (talk) 22:06, 9 November 2019 (UTC)
  • Symbol oppose vote.svg Oppose Abbreviations tend to form a cryptic language readable only by experts. They can be a problem for new users if they are too many. --Geraki TLG 14:53, 11 November 2019 (UTC)


Are the redirects automatic, or would they need manual creation? If they are automatic (e.g., TEM:Wikidata Infobox), then this seems reasonable, but if they need to be manually created then it sounds like it would be an unnecessary mess... Thanks. Mike Peel (talk) 15:24, 28 October 2019 (UTC)

@Mike Peel: They will be automatic. In fact, it isn't a "redirect", but another way to type the namespace's name (maybe we can call it an alias). It also works vice versa; you can type Commons:VPP instead of COM:VPP, there is no difference. Ahmadtalk 16:46, 28 October 2019 (UTC)
Thanks for the clarification. In that case, I'm neutral on these proposals. Thanks. Mike Peel (talk) 16:53, 28 October 2019 (UTC)
  • Pictogram voting comment.svg Comment Proposal for UT split off from the proposals for TEM: and MOD:. (phab:T237177) - Alexis Jazz ping plz 08:28, 3 November 2019 (UTC)

Autopatrol edits made with the translation tool or create a new group[edit]

When translators who do not have autopatrol right translate things, their edits stay unpatrolled until a patroller marks them as patrolled. We have a different translation reviewing system, translation can be reviewed by those who have the translate-messagereview right. Currently any logged-in user can review translations. In addition to that, translations have to be approved by translation admins. So let's count the steps for reviewing an unautopatrolled translator's translations.

  1. Review by a patroller and marking the edits as patrolled
  2. Review by another translator (optional)
  3. and lastly acceptance by a translation admin.
This unnecessarily increases the backlog of unpatrolled edits. So if we can just omit the first step, we'll be able to reduce a lot of unpatrolled translations from the backlog. We have plenty of trusted translators here and their translations do not need to patrolled. Autopatrol might not be the best fit for users who are only here for translating things.
For example, this user Worrida (just a random example I found while patrolling). Their upload count is zero, and they are only here for translating pages and templates.
Some links to recent changes and new pages backlog
  • Either autopatrol translations as I said above
  • Or create a new user group whose translations would be autopatrolled

Autopatrol edits made with the translation tool or create a new group: votes[edit]

  • Symbol support vote.svg Support as proposer. I am fine with either way. Masum Reza📞 11:28, 30 October 2019 (UTC)
  • Symbol oppose vote.svg Oppose the translation tool can be used for the same vandalism like every page. And there is a huge backlog of unchecked translations. I think it would be better to give autopatrol rights to users doing more translation. --GPSLeo (talk) 09:37, 31 October 2019 (UTC)

Autopatrol edits made with the translation tool or create a new group: discussion[edit]

  • Are you sure about the last step: "lastly acceptance by a translation admin"? As far as I know, translations do not need to be accepted by a translation-admin. 4nn1l2 (talk) 11:59, 30 October 2019 (UTC)
    Thanks for noticing. I've struck out those sentences. Masum Reza📞 12:15, 30 October 2019 (UTC)
  • @GPSLeo: Autopatrol rights are given to trusted editors who understands our policies (including copyrignt policies). IMO there is no reason to assume that a user who is only here for translating things would also be familiar with our policies about copyrignts. But you do have a point. How about we just create a group called "Translators" or something? Their edits related to translation will be autopatrolled. Masum Reza📞 09:49, 31 October 2019 (UTC)
I only want translations automatically marked as patrolled it the user is trusted. The texts are getting translated are often guidelines and other important pages. If I can not trust the user I want to patrol the edits or at least some and mark all manually as patrolled. Autopatrolled users do not have to understand every copyright rules for this we have the license reviewers. --GPSLeo (talk) 13:25, 31 October 2019 (UTC)

Shutdown Wikimedia Commons Welcome bot[edit]

I would like to propose that the Wikimedia Commons Welcome (talk · contribs) bot be shut down. This bot currently gives an automated welcome message to all accounts automatically created here, and not all participate in good or any editing. Some with usernames that require suppression have auto-created talk pages from this bot, and creates extra work. Majority of new users who first upload here don’t even read it, proven by the everyday backlog of CAT:CV. A bot mass creating user talk pages with majority not reading it is an issue. Seeing how an automated Echo notification issues a welcome message to new users (MediaWiki:Notification-welcome-link linking to Commons:Welcome), this bot is now redundant and should no longer be running. A similar proposal happened at Meta causing their welcome bot to be shut down since 2015. 1989 (talk) 04:47, 5 November 2019 (UTC)

  • Symbol support vote.svg Support as proposer. 1989 (talk) 04:47, 5 November 2019 (UTC)
  • Symbol support vote.svg Support --Zhuyifei1999 (talk) 04:56, 5 November 2019 (UTC)
  • Symbol support vote.svg Support -- (Talk/留言/토론/Discussion) 06:38, 5 November 2019 (UTC)
  • Symbol support vote.svg Support I didn't read that when I was a newbie, my sockpuppet didn't read that. Who reads that? Answer: The dumb bot itself. -- Eatcha (talk) 06:47, 5 November 2019 (UTC)
  • I am having Symbol neutral vote.svg Neutral feelings about this. We don't really need to shut down helpful messages to newbies. Though I have noticed that most new users don't read those messages. I think new Growth features would be more helpful. I am soon going to propose a proposal about that here. Masum Reza📞 06:55, 5 November 2019 (UTC)
  • I would at least support having the bot post the welcome message after the first edit by the user instead of upon account creation. And in addition to manually created accounts. (created on Commons) Many automatically created accounts have no intention of contributing here, they simply clicked on an image on Wikipedia. I have to test the notification to new users before I support shutting the bot down completely. - Alexis Jazz ping plz 07:37, 5 November 2019 (UTC)
  • Symbol oppose vote.svg Oppose I like these welcome messages. But maybe we can update the content of it. --GPSLeo (talk) 08:40, 5 November 2019 (UTC)
  • Symbol oppose vote.svg Oppose Would prefer to see a more intelligent welcome bot as suggested by others, rather than just switching it off. Before a welcome bot was conceived, we spent many happy hours responding to questions from new users that were welcomed using one of several varieties of English Wikipedia welcome template (in days of yore I was a Wikipedian not a Commonser, ref WP:WT). There's a lot to be said for welcoming a new but apparently active contributor with a personalized message based on their interests, by a long term contributor with similar interests. There are ways of doing both at the same time, so maybe someone can think about a proposal with a state machine behind it that makes it possible? -- (talk) 11:19, 5 November 2019 (UTC)
  • Symbol oppose vote.svg Oppose This appears to be a solution that looks to find a problem. If 99% of users do not read the welcome message, then A) 1% of users do read it B) We can talk about making that number higher. I do find that currently it is too cluttered, but that is not a reason to disable it. ℺ Gone Postal ( ) 12:04, 5 November 2019 (UTC)
  • Agree with others. Setting it to send the welcome message after, say, one or two edits is a better idea. Also, I think we should change the template. I didn't read it when I was a new user. A new user can learn things like how to sign, using babel boxes, linking to files, enabling gadgets, using tools and maybe tagging images with {{Speedy deletion}} later, if needed. Newbies can ask for deletion of a file at the help desk, and someone will most probably tag the image for SD and show them the ropes. Also, you can see many new users not signing their message in COM:HD, which probably means that they don't read the welcome message. We need a message that can truly help the inexperienced user to become familiar with Commons. Ahmadtalk 12:30, 5 November 2019 (UTC)
  • Pictogram voting comment.svg Comment I'm not totally on board with disabling the bot outright. However, I do think it needs quite a bit of tweaking. If I had to propose something, it would be that the bot only leaves a welcome message after the user has made ten consecutive edits without receiving a warning for copyright or vandalism. If they make nine edits, and then receive a warning for the ninth edit, then the timer resets, and they must make ten more consecutive constructive edits. I have no idea how you technically implement that however.
For throw-away vandal accounts, this should avoid a lot of unnecessary page creations. Otherwise, for good faith newbies who simply don't understand policy, these are users who need to be reading the warnings they are given, and not reading a generic welcome template. Keeping in mind that for basically every other website, new messages go at the top, and old messages go at the bottom. There is a real possibility that new users will click the notification, read the top message, and miss the warning all together.
I also agree with Ahmad, that the current template is information overload. Much of it is written for experienced users on other projects coming to Commons for the first time, and not for genuinely new users. It should be half the size, with half the links, should offer a clear explanation of what Commons is to begin with, and should only point users to absolutely essential places. I'm happy to try to collaborate with anyone to come up with a more minimalist replacement. GMGtalk 13:31, 5 November 2019 (UTC)
  • Good points in the OP, but I have to Symbol oppose vote.svg oppose, per Alexis Jazz and Fæ. -- Tuválkin 14:39, 5 November 2019 (UTC)
  • Symbol oppose vote.svg Oppose we can improve the design, text, and simplify the massage to be easier to be read, however do not shut down. We already have a lot of issues of people not reading what we do.-- Rodrigo Tetsuo Argenton m 17:14, 8 November 2019 (UTC)
  • Symbol support vote.svg Support we can bring it back once it's fixed. The message says "Do you want to have your recently uploaded picture removed? Tag it as {{speedy|reason here}}" - yet users are still sending their uploads to DR daily, proof nobody reads it.--BevinKacon (talk) 10:49, 10 November 2019 (UTC)
  • Symbol oppose vote.svg Oppose, for years many users have been welcomed by it and many people who have no idea how Wikimedia Commons works or what it is will have no idea what this is and what it stands for. There is no reason to end this bot and simply comparing it to other Wikimedia websites where such bots were shut down is bad, if you'd ask any random person in the streets where images on Wikipedia come from they will very likely not know that it's Wikimedia Commons. The bot links to the help desk, the village pump, Commons policies regarding licensing and copyright and what people are and aren't allowed to do here. If everyone has to discover this by themselves more mistakes will be made which means more backlog. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:55, 11 November 2019 (UTC)
  • Symbol support vote.svg Support The custom of welcoming users is one of the older customs in wikimedia projects. The most important mission and result of such message is that new users become aware that they contribute in a project where other real persons contribute. This is what creates empathy for other users. So, imho an automated welcome message that is signed by bot and/or in the history makes clear that it was created by a bot does not fulfil this need and mission. New users should never get confused with complex wiki markup in their own talk page, or even a template (since most probably they do not yet know what a template is). They can always get guided through the existing help pages, so no need for long lists of links to them. Echo notification fulfils the automatic welcoming. First welcome message should be from real user, usually before addressing some issue with the user's uploads. So, shut down the Welcome bot and make notification scripts add a simple welcome template before for example {{Idw}} if it is the first edit on the page. --Geraki TLG 15:07, 11 November 2019 (UTC)
    • But does this happen in reality? A simple look at other Wikimedia projects showcase that many users aren't ever welcomed and even the English language Wikipedia (the most popular Wikimedia website) has some level of bots welcoming new users but also has bots undoing edits, if you add a link you did not now was locally blacklisted you will get all of your edits rolled back. But here is a serious question, what are the most common messages left on the user talk pages of new users? It's certainly not welcome messages or thanks for uploading files, they're impersonal automated deletion request messages. If most new users were only welcomed with these messages without any indication that they are welcome I am sure that our retention of new editors would be even lower. And how do you suppose for people to find many help pages if they aren't often immediately linked to? The welcome message currently is really the only "hub of information" available to new users and just because some users don't read it doesn't mean that no new users do. New products always include an instruction manual simply to fall back to and not everyone immediately reads all instruction manuals they have ever received but it's better to have it for the people that do want it than remove it for everyone. Also welcoming new users with a pre-written message would just cost volunteers countless of hours of more time, removing the automated messages is a net deficit. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:57, 12 November 2019 (UTC)

Namespace alias T: for Template:[edit]

So, turns out that TEM is actually the language code for Temne, a language with 2.5 million first-language speakers.


T: as an alias for Template: is already in use by itwiki (Italian), hiwiki (Hindi), zhwiki (Chinese), and ruwiki (Russian) as well as some sister projects. English Wiktionary also has this alias. So if the WMF ever decides to create a new project with T: interwiki, they'll have to deal with all those projects anyway. This may even discourage the WMF from ever wanting to use T: for interwiki. - Alexis Jazz ping plz 08:50, 6 November 2019 (UTC)

Namespace alias T: for Template: votes[edit]

  • Symbol support vote.svg Support - Alexis Jazz ping plz 08:50, 6 November 2019 (UTC)
  • Symbol support vote.svg Support - per Alexis Eatcha (talk) 08:55, 6 November 2019 (UTC)
  • Symbol support vote.svg Support Now I support this proposal (which was the original proposal). To be clear, I oppose TEM‌ for Template, because it is too long as a shortcut for such a common namespace with 192,484 pages on Commons as of now. 4nn1l2 (talk) 09:56, 6 November 2019 (UTC)
  • Symbol support vote.svg Support -- Tuválkin 11:36, 6 November 2019 (UTC)
  • Symbol support vote.svg Support.--Vulphere 04:34, 7 November 2019 (UTC)
  • Symbol oppose vote.svg Oppose - I do not like short names and short aliases as they make things less readable. It is unclear to me what would be the benefit. --Jarekt (talk) 17:52, 8 November 2019 (UTC)
    The whole purpose of these aliases are to reduce the typing time of volunteers. And there are some lazy people who want this. Now then do you have any other reason for opposing besides w:en:WP:IDONTLIKEIT? Masum Reza📞 12:21, 11 November 2019 (UTC)
  • Symbol oppose vote.svg Oppose - Per Jarekt. Multichill (talk) 22:04, 9 November 2019 (UTC)
  • Symbol support vote.svg Support, But I wish we could have {{ as well. Sometimes I just type {{ in the search box, then I have to delete it and start typing Template: instead. Anyways, T: makes searching and typing easier, also per 4nn1l2. Ahmadtalk 12:03, 11 November 2019 (UTC)
  • Symbol support vote.svg Support, + Ahmad252's proposal. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:46, 11 November 2019 (UTC)
  • Symbol oppose vote.svg Oppose 1) Abbreviations tend to form a cryptic language readable only by experts. They can be a problem for new users if they are too many. 2) T: could also be an alias for Talk: namespace, and this illustrates that abbreviations are not really helpful. --Geraki TLG 14:54, 11 November 2019 (UTC)

Namespace alias T: for Template: discussion[edit]

@4nn1l2: actually that original proposal wasn't for a namespace alias but only for a search box shorthand. Though I think most of us, including me, missed that. - Alexis Jazz ping plz 10:50, 6 November 2019 (UTC)
@Alexis Jazz: Sarang said 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. H is indeed an alias for Hilfe (Help) namespace on the German Wikipedia
'+dewiki' => [
		'P' => 100,
		'PD' => 101,
		'H' => NS_HELP,
"Search box shorthand" is part of the package of an alias. 4nn1l2 (talk) 11:12, 6 November 2019 (UTC)
I'm only repeating what Sarang explained. I think most of us were confused. - Alexis Jazz ping plz 11:15, 6 November 2019 (UTC)

Using MediaWiki:WatchlistNotice to neutrally advertise advance permission requests[edit]

After a village pump thread was started regarding this topic I thought it would be prudent to just start an official proposal and let the community decide if this is an appropriate action going forward. There are four advance permission requests that would need to be discussed. Administrator, Oversight, CheckUser, and Bureaucrat. If announcements are approved by the community they will be translated into as many languages as possible and they will be neutrally worded. Proposed wording for each announcement is included in the specific sections below. In the rare event where there is a mix of requests currently open for discussion multiple notices will be posted to maintain translations. Please voice your thoughts, concerns, criticisms, etc. in the discussion section. --Majora (talk) 12:16, 6 November 2019 (UTC)

RfA announcements
Proposed wording: A request for adminship is currently open for discussion.

Proposed wording if multiple requests are active: Multiple requests for adminship are currently open for discussion.

RfB announcements
Proposed wording: A request for bureaucratship is currently open for discussion.

Proposed wording if multiple requests are active: Multiple requests for bureaucratship are currently open for discussion.

CU announcements
Proposed wording: A request for checkuser rights is currently open for discussion.

Proposed wording if multiple requests are active: Multiple requests for checkuser rights are currently open for discussion.

OS announcements
Proposed wording: A request for oversight rights is currently open for discussion.

Proposed wording if multiple requests are active: Multiple requests for oversight rights are currently open for discussion.

Discussion (notices)[edit]

This proposal makes the false premise that Watchlist notices are necessary. What's wrong with VP notices? -- (talk) 12:29, 6 November 2019 (UTC)

Pretty sure that there are plenty of editors that just go about their daily business without ever having a look at the VP. They may not even understand the discussions there due to language barriers, but they would probably still like to be informed about ongoing votes. For self-proclaimed multi-lingual project we already have an incredibly strong bias towards the use of English. Standardized, translated messages for votes could be one way to reduce that a bit. --El Grafo (talk) 12:42, 6 November 2019 (UTC)
  • Symbol support vote.svg Support for RfB, OS, and CU votes. But NOT for RfA votes, as they should not be a big deal. No need to advertise adminship requests on Commons. Becoming an admin is relatively easy on Commons (unlike some infamous and failed projects) and I really like that. A minimum of 8 support votes for a successful RfA proves the self-confidence of this community to me (bad admins can be dealt with). No problem in RfAs --> No fixes. 4nn1l2 (talk) 12:31, 6 November 2019 (UTC)
  • Pictogram voting comment.svg Comment I miss RfA's on a regular basis because even though I've watchlisted the relevant pages, the single edit to that page that starts a new RfA easily gets lost among all the other things on my watchlist. --El Grafo (talk) 12:36, 6 November 2019 (UTC)
@: My personal view on the matter is that watchlist notices are just that, a notice. While a VP notice is a whole thread. Semantics, I know but an important distinction in my mind. Even if started neutrally it is impossible to keep threads that way and my personal belief is that all discussion about the permission request should remain on the subpage. Bifurcating the discussion only leads to problems. The watchlist notice is not a thread and cannot be edited by anyone other than sysops, and with a defined wording it can't really be edited to be non-neutral at all. --Majora (talk) 12:45, 6 November 2019 (UTC)
It would make sense if this proposal had no dependency on watch lists but were just about notices. How the implementation works is a separate issue. -- (talk) 12:54, 6 November 2019 (UTC)
Sorry I had to go to work so my responses may be a little sporadic for a little while. That discussion is for disabling the gadget that assists in posting watchlist notices. The MediaWiki space and its behavior is created and set by the system itself. That is why they are called "system messages". You can't turn off a system message by disabling a gadget. It doesn't work like that. Watchlist notices will continue to be able to be posted regardless as they are part of the system. --Majora's Incarnation (talk) 13:04, 6 November 2019 (UTC)
Thanks for clearing that up! --El Grafo (talk) 13:38, 6 November 2019 (UTC)
@Majora: Um no? MediaWiki:WatchlistMessageCreator.js and MediaWiki:Gadget-WatchlistNotice.core.js are two separate things and neither of them are core. The linked discussion is to drop them since someone has to maintain them. --Zhuyifei1999 (talk) 17:55, 6 November 2019 (UTC)
@Zhuyifei1999: Fair enough. The actual watchlist notices are stored at MediaWiki:Watchlist-summary which requires no actual script to run. As I said, watchlist messages are part of the system. You don't necessarily need another script to produce them. --Majora (talk) 18:11, 6 November 2019 (UTC)
  • I have played with the idea of advertising some important stuff before. Because it couldn't be fully automated, I dropped it. Considering this proposal isn't fully automated either, perhaps it's time to pick that up again. The basic idea was simple: a notice box of some sort on all the village pumps/noticeboards or other high traffic pages (help desk?) that links to stuff. Users who never visit those pages could add the same notice box to their own talk page, it would be nothing but a template after all. - Alexis Jazz ping plz 13:24, 6 November 2019 (UTC)
    We have that already. Template:Centralized discussion. Nobody uses it though and judging by your post perhaps you didn't know that it has been displayed at COM:VP for quite some time? That is the problem with templates like that. Banner blindness eventually renders the entire space moot in one's mind. A disappearing and reappearing notice on a watchlist would combat that mental quirk. If you want something more automated I'm sure we can find a bot operator willing to set something up. That is what enwiki has. An automated watchlist notification system and, as I've mentioned before, their system is one of the very few things I like about their system of governance. --Majora's Incarnation (talk) 13:31, 6 November 2019 (UTC)
    Good grief, I just had a ghastly vision of piled up watchlist notices filling half my mobile phone screen, each hard to click on without going to whatever page I'm not actually interested in. If this gets passed in some fashion can we please ensure that notices are limited to a monthly quota, and that at least half the time there are zero watchlist notices popping up, just to ensure our real estate is not so littered with junk that we either become notice-blind, or end up disabling notices altogether? If necessary those requesting 'advanced' rights can always refrain from 'going live' until they have a notice slot. -- (talk) 13:44, 6 November 2019 (UTC)
    Oh yeah. The vast majority of the time there will be no notice whatsoever and I prefer that. Requests for advanced permissions are relatively rare and requests for highly advanced permissions are even rarer still. Each notice can also be dismissed which is saved in a cookie so it does not reappear. In the rare event that there are multiple requests and the "multiple" notice has to be used when it is downgraded to a singular request the same cookie signature can be used so those that have dismissed it don't have it pop back up again. --Majora's Incarnation (talk) 13:57, 6 November 2019 (UTC)
@Majora: I indeed missed that. For two reasons, I think:
  1. It doesn't seem to be updated regularly. I'm not going to look at something that doesn't actually inform me.
  2. The template is buried by this massive "Welcome to the Village pump" box which is virtually useless for me and a completely irrelevant image of an actual bloody village pump. I have to scroll before it becomes visible. No, I'll never notice that because new messages are at the bottom of the page.
And seriously, that massive "Welcome to the Village pump" box is a total bore. Have I read the FAQ? HAVE I!! I don't use the "COMMONS DISCUSSION PAGES (index)" either. What's the blue bar at the top for, then? Why do we have two navigational templates? And what's the point of the daily headers anyway, besides needlessly inflating the TOC? - Alexis Jazz ping plz 14:31, 6 November 2019 (UTC)
  • WRT cookies, in the same day I might read or edit from phone, tablet, laptop. Cookies don't necessarily stop me from having to click off the same notice multiple times, in practice, I just ignore them unless they are really large and irritating (yes, some are annoyingly large, especially on mobile devices using desktop view rather than the cruddy mobile view). -- (talk) 14:08, 6 November 2019 (UTC)
    Yes Template:Centralized discussion does not work, I just don't see it any more. Which brings me to my only concern about this proposal: The watchlist notice looks so much like the rest of the Watchlist that I don't see it either. (apparently on mobile that's a different matter)--El Grafo (talk) 13:46, 6 November 2019 (UTC)
    Unfortunately, it is going to be hard to combat that entirely. I don't really use mobile so I can't speak to that but in normal watchlists, at least for me personally, I saw the OS notice pretty immediately. I really do feel like this type of notice is rare enough to maintain a sense of novelty so that it is not ignored. And per above, I don't see them become so common as to cause issues as advanced permission requests are rather rare to begin with. --Majora's Incarnation (talk) 13:57, 6 November 2019 (UTC)
    Well, I could probably just edit my common.css to make watchlist notices pop out a bit more for myself … --El Grafo (talk) 14:09, 6 November 2019 (UTC)
  • (Edit conflict) I think makes a good point above. There are two separate but related questions to discuss and ultimately decide that are being mixed up a bit here:
  1. Do we want some kind of central notification of RfA/B/CU/OS?
  2. If yes, how do we implement this? (Watchlist notice is one option, but we also have Site notices, Template:Centralized discussion, and maybe more)
Personally, I would very much welcome some kind of systematic notification, but I'm not sure about what would be the best way to do it --El Grafo (talk) 14:03, 6 November 2019 (UTC)
I don't think site notices are the best option here as they appear on every page by design. You want to talk about banner blindness and intrusive announcements? Site notices inherently have both of those problems. If we want to try to use the centralized discussion template more that could be possible but we might have to redesign it so that people pay attention to it again. --Majora's Incarnation (talk) 14:22, 6 November 2019 (UTC)
Just want to make sure we consider all possible options … --El Grafo (talk) 15:47, 6 November 2019 (UTC)
  • The complaint about the proposal assuming we do want watchlist notices does rather suggest everyone is just going to vote rather than have a discussion first. Can we not do that please. I think all such requests should be posted and disagree with 4nn1l2 that adminship should be exempt. Quite often the only time I notice an adminship request is when someone closes it. The whole active community should be informed for all such posts. Also agree with Majora that VP posts are problematic, though we then need to make sure the Watchlist notice format is neutral. I don't think Majora's proposed notices are ideal because they do not name the user who is proposed. Therefore one will not easily tell that this is a different request to what you saw yesterday but forgot to dismiss. We have automated bots for processing feature picture nominations and a process for deletion requests, so I don't see why some clever person can't figure out an automatic way that new user nominations automatically create/modify the watchlist notice. I'm sure it isn't rocket science to combine if there are multiple concurrent requests. An automatic system could also detect a withdrawn nomination and remove the notice. As others have pointed out, it would be best if the notice was less invisible than it currently is. -- Colin (talk) 14:24, 6 November 2019 (UTC)
    Perhaps this question has too many facets to really be resolved with one proposal. Perhaps we should first have a discussion on whether or not we should have these notices at all. Since there appears to be disagreement as to which permission requests should have them. If that is decided in the affirmative then we can have a more focused discussion on the form and location. Do people think that would be more prudent here? --Majora (talk) 17:25, 6 November 2019 (UTC)
  • In my opinion the benefits outweigh the negatives, with user rights like these we want to make sure that those in these positions have "the consent of the community" which shouldn't be restricted to only a handful of users that happen to watch these pages. But de-sysop requests and other requests for the removal of rights should also be included. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:03, 12 November 2019 (UTC)

Votes (notices)[edit]

  • Symbol support vote.svg Support This would be useful, and matches what is used on enwp watchlists. Presumably the messages would display in the user's language? I think it would be better if usernames were specified in the watchlists, so that it's not necessary to click through to see if you know the person or not (as you're more likely to want to comment either positively or negatively if you know them), but I suspect there are good reasons for enwp not doing that. Thanks. Mike Peel (talk) 14:47, 6 November 2019 (UTC)
    I noticed this question wasn't answered. Yes, Mike Peel. The message will display in the user's language using {{LangSwitch}}. Something like {{RfX watchlist notice}} would be used. I just threw that together quickly so of course you should not assume that is the final product. --Majora (talk) 02:25, 12 November 2019 (UTC)
  • Symbol support vote.svg Support - I support all of the above named user rights. Yes, RfAs are more common, but I miss them all the time. ~riley (talk) 19:22, 6 November 2019 (UTC)
  • Symbol support vote.svg Support -- CptViraj (📧) 02:50, 8 November 2019 (UTC)
  • Symbol support vote.svg Support -- Eatcha (talk) 04:13, 8 November 2019 (UTC)
  • Symbol support vote.svg Support but users should be able a to turn off these notices. If not, then Symbol oppose vote.svg Oppose. Masum Reza📞 10:23, 8 November 2019 (UTC)
    @Masumrezarock100: You can dismiss them but as of right now I'm now aware of a quick way you can fully turn them off without doing your own .css styling in your preferences. This would be true for all system notices. As mentioned above dismissal and hiding is done via cookies so it has its limitations. The .css styling to permanently turn them off is not hard (1 or 2 lines). So those instructions could be included somewhere such as enwiki does. --Majora (talk) 17:48, 9 November 2019 (UTC)
    @Majora: ..or stuffed into a gadget. - Alexis Jazz ping plz 18:13, 9 November 2019 (UTC)
  • Symbol support vote.svg Support, sysops should have the mandate of the community and not just "Metacommonists" (those who watch these pages and other "community pages"), this will encourage wider participation of even more users. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:05, 12 November 2019 (UTC)

We don't have enough videos, some proposals to Improve the issue of meagre video files on Wikimedia Commons[edit]

As per Special:MediaStatistics less than 1% of our files are videos, in size 4.97% of our total storage is video.
Q Why do we need more video?

  • A Visual stimulation grabs users’ attention, our goal of developing and maintaining open content, wiki-based projects and providing the full contents of those projects to the public free of charge is incomplete without educational videos.

Q How does a normal-user upload video (at present)?

  • A They either use FFmpeg(or any other video conversion tool) or upload via Commons:video2commons. Please note that new users are not aware of Video2commons and it's also restricted to AutoConfirmed Users for obvious reasons. Users editing through tablets/phones/phablets/cheap computers can't uses FFmpeg as it's slow.

Q Are we ignoring this problem?

  • A You know better, than I do.

Q Would it break WMF's server?

  • A Commons:video2commons runs on WMF server, it doesn't break it. WMF has enough processing power to handle the conversion.

Please feel free to oppose any of the following proposals, but don't forget to provide a realistic solution to increase the number of videos on Wikimedia Commons.

Proposal 1: Support conversion of MP4 files to open format like WebM & delete/nuke the MP4 file after uploading the transcoded Webm file[edit]

  • Most of the Video cameras record in MP4, smartphones record in mp4. The uploader is required to convert the video to Webm, otherwise, they can't upload to commons.
  • Conversion takes too much time(sometimes even days), expensive computers, etc.
  • It should be understood that videos would be recorded in MP4 no matter what we do, now conversion can either be done on the uploader's computer or WMF's servers.
  • By doing the conversion on the WMF server we can increase the number of video files. And by deleting the mp4 file, we are not hampering with WMF's goal of supporting open-source.
  • By not allowing the conversion on WMF servers we are certainly hampering upload of many educational videos.

Votes for Proposal 1[edit]

  • Symbol support vote.svg Support As the suggester -- Eatcha (talk) 10:08, 8 November 2019 (UTC)
  • Symbol support vote.svg yes, please. Many content creators can't upload educational videos to Commons because it doesn't support uploading of mp4 files. Masum Reza📞 10:51, 8 November 2019 (UTC)
  • Symbol support vote.svg Yes, please, I have tried uploading videos before discovering Video2Commons but gave up until I found out about the tool. A lot of newbies or just general users who do want to upload video files to Wikimedia Commons will be empowered to do so if this proposal gets accepted. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:43, 11 November 2019 (UTC)

Discussion for Proposal 1[edit]

With regard to the upload of a non-free mp4, these do not have to be visible on Wikimedia Commons, so the proposal as written is unnecessarily complex or negative.

The upload process puts the file on a WMF server where there are some checks and information like EXIF data is parsed in order to create the page that later appears on Commons. A video pre-processing stage can occur at that point, which can logically either reject the video file due to parsing errors, unrecognized codecs, any other type of error, or successfully release the webm version. The mp4 original could be retained in a file archive as a potential future reference, including the advantage of being able to automatically re-process the video should the pre-processing software be upgraded or indeed being able to release the mp4 should Commons policies change or the nature of the copyrights for that format change. -- (talk) 11:08, 8 November 2019 (UTC)

Proposal 2: Allow uploading of MP4 files, only provide transcoded Webm files to download/stream.[edit]

  • Keep MP4 files, don't allow download of MP4 files nor streaming.
  • Instead, stream Webm version of the MP4 files and allow Webm version of the MP4 file to be downloaded.
  • It doesn't promote MP4, as we are disabling download and streaming. Users can no way get he MP4 file that was uploaded.
  • On August 26, 2010, MPEG LA announced that royalties won't be charged for H.264(patent expiring in 2027) encoded Internet video that is free to end-users.

Votes for Proposal 2[edit]

  • Symbol support vote.svg Support -- Eatcha (talk) 10:09, 8 November 2019 (UTC)
  • Symbol support vote.svg Support Kaldari (talk) 16:00, 12 November 2019 (UTC)

Discussion for Proposal 2[edit]

There is no advantage in "displaying" a mp4 that reusers cannot access, or viewers see. For this reason it's really the same as proposal 1 in my eyes, as the choice of whether to keep an original video in the filearchive is the same issue. -- (talk) 11:12, 8 November 2019 (UTC)

I think the implied difference is that under this proposal the MP4 files would more easily be made available for streaming and downloading in 2027 (once all the patents have expired), without requiring undeletion of all the source files. Kaldari (talk) 16:00, 12 November 2019 (UTC)

Proposal 3: Use AV1 codec instead of VP9/VP8 as the main codec, (AV1 is new and better free codec)[edit]

  • AV1 is a new and better free codec then VP9, AV1 can use WebM, mkv, and mp4 as a container.
  • It was developed as a successor to VP9 by the Alliance for Open Media (AOMedia).
  • Tests from Netflix showed that, based on measurements with PSNR and VMAF at 720p, AV1 was about 25% more efficient than VP9 (libvpx).
  • Similar conclusions with respect to quality were drawn from a test conducted by Moscow State University researchers, where VP9 was found to require 31% and HEVC 22% more bitrate than AV1 for the same level of quality.
  • Facebook showed about 40% bitrate savings over VP9 when using a constant quality encoding mode.

Votes for Proposal 3[edit]

  • Symbol support vote.svg Support -- Eatcha (talk) 10:09, 8 November 2019 (UTC)

Discussion for Proposal 3[edit]

  • There is a lot of arguments here without any evidence. Masum Reza📞 10:20, 8 November 2019 (UTC)

@Masum Reza📞 Here you are:

There does not need to be a proposal agreed for this to proceed as a task on Phabricator. As this is a fairly technical point, and there may be operational issues that are not known here, but might be known to the Phabricator community, it makes sense to start the Phabricator discussion anyway. -- (talk) 11:11, 8 November 2019 (UTC)

Proposal 4: Integrate any open-source video conversion suite inbuilt the commons android/IOS app[edit]

  • It should facilitate the uploading of videos directly from smartphones, as users don't need to download an extra app to convert video. (It's gonna be very slow BTW, due to less processing power of phones)

Votes for Proposal 4[edit]

  • Symbol support vote.svg Support -- Eatcha (talk) 10:10, 8 November 2019 (UTC)
  • Symbol oppose vote.svg Oppose Idea is good but we want high quality and not fast encoded content. That is not possible on mobile devices. Even on a high end desktop most encodings can not run in real time. --GPSLeo (talk) 09:46, 9 November 2019 (UTC)
  • Symbol oppose vote.svg Oppose I tried running this on OnePlus 7TP, and it can't even transcode the videos recorded using the device itself. And of course, you can fry eggs after transcoding 4K videos. Transcoding must be done on WMF servers. --Eatcha (talk) 15:15, 9 November 2019 (UTC)
  • Symbol oppose vote.svg Oppose Legal hell. (actually not so much "hell" as "it's going to cost millions of dollars in patent licensing") - Alexis Jazz ping plz 16:03, 9 November 2019 (UTC)

Discussion for Proposal 4[edit]

Devolving processing to the client side may make sense, or not. I would like to see some trials of what the outcomes or (dis-)benefits to the user experience are. Expecting users to wait for an hour for a 4 minute video to be pre-processed and hogging resources on their phone during that time, would not be a workable scenario. -- (talk) 11:16, 8 November 2019 (UTC)

No longer allow CommonsHelper imports from kowiki[edit]

Now that FileExporter (a Copy to Commons tool) is already a non-beta feature in kowiki, CommonsHelper is already redundant for that purpose in kowiki. Calvinkulittc 03:04, 9 November 2019 (UTC)

Displaying multiple images in the Wikidata Infobox using Javascript[edit]

Hi all. I would like to modify {{Wikidata Infobox}} so that it uses a Javascript switch to show the images that are linked to via image (P18), collage image (P2716), image of grave (P1442), image with frame (P7420), image backside (P7417), photosphere image (P4640) and other properties. It will only show one image for each property. The current version displays some of these images, one above the other, so this change would simultaneously decrease the screen space that the infobox uses, and show more images that are linked to from Wikidata. The modification is coded up in {{Wikidata Infobox/sandbox}}, and you can see it live in these categories if you enable the 'Infobox' gadget in your preferences, for example see Category:Presumed portrait of Guillaume Filastre. Unlike the regular updates to the infobox, this requires a modification to MediaWiki:Common.js, and after a discussion with the interface admins, it seems that this requires community consensus to enable the javascript/gadget by default - hence this proposal. Please {{Support}} or {{Oppose}} below! Thanks. Mike Peel (talk) 21:07, 9 November 2019 (UTC)


  • Symbol support vote.svg Support --Eatcha (talk) 14:27, 10 November 2019 (UTC)π°

Photography taken in Azerbaijan[edit]

It´s possible that I might travel to Azerbaijan in the near future. What are the most important rules for photographs and photographers?--2A02:8070:A380:8E00:2DAD:3503:9DF4:68FB 21:33, 12 November 2019 (UTC)

COM:Azerbaijan gives a basic overview but I'd say a pretty important fact is that there is no freedom of panorama there. So anything still under copyright by their creator cannot be photographed even if it is in a public place. This includes works of art, buildings, etc. More of less be careful where you point your camera if you want to upload it here under a free license. Thank you for taking the time to ask beforehand though. For future reference, this type of question would be better suited at the copyright section of the village pump. --Majora (talk) 03:36, 13 November 2019 (UTC)
So this comes down that I can only upload the "old stuff". Does it apply also to modern gouvernment buildings like town halls or administrative buildings? Further more, is there a law that prohibits photos of military facilities or troops, police stations, jails etc. I tend to shoot not only the "nice" things but the controversial things as well. I don't want to go there, but just in case: Which law applies in Nagorno-Karabakh? It might be the case that I can shoot something out of the sky or from a nearby mountain with a long telephoto lens. And my last question does the copyright part also apply to city views. I mean it is impossible to shoot a panorama of the city without having some new buildings in the frame, that are protected by copyright laws.--2A02:8070:A380:8E00:383A:DBF9:5A71:752F 19:55, 15 November 2019 (UTC)
Yes it would. If the building has enough features as to meet what is known as the threshold of originality and it is new enough to still be within copyright then a photograph of it cannot be taken. What is considered "original" is often up for debate if the building is plain looking so overall I would say that you should avoid taking up close photos of newer buildings in general. As for other local laws, such as the prohibition of photos of certain places, we cannot tell you that here. We are not lawyers and while we have knowledge of copyright laws for certain countries other area of the law we just do not. If you have questions about that I'm afraid we can't assist you. Copyright laws are generally country based. Not regional. So the copyright laws of Nagorno-Karabakh would generally be the same as what is listed on the COM:Azerbaijan page. As for city views that is more complicated. A copyright concept called de minimis would apply here. If the copyrighted buildings are inconsequential to the overall photograph it doesn't matter and you can take photos of them. That is why I said "up close" in the sentence talking about building copyrights. You should really read the page on de minimis to understand this concept. As mentioned. It is rather complicated. However, if the building is not identifiable and its presence is just a consequence of the overall photo then it would fall under the first example listed at COM:DM#Guidelines. Although these photos are subject to deletion request review to glean the opinions of other members of Commons. --Majora (talk) 22:31, 15 November 2019 (UTC)
OK, this is what I understand: I can upload images of "old" buildings and artworks, but I need to check if "old" applies. Plain buildings, that have no special architectural features on them (as traditional kind of architecture or run of the mill architecture like standard bousing blocks) are not of much concern, even if they are more recent. I can upload panorama images showing copyright protected buildings if they are only a small and not dominating part of the picture, so as an experienced fotographer I understand and can apply the de minimis concept. You can not provide or are unwilling to provide lawful information about official buildings and/or military facilities, military equipment or troops or you are not aware that there is any regulation concerning these subjects.--2A02:8070:A380:8E00:EDB9:B1EE:9EC4:847 12:21, 16 November 2019 (UTC)

Add all rights of Autopatroller group to file mover, translation administrator, GWToolset users and template editor groups[edit]

The requirements for file mover, translation administrator, GWToolset users and template editor rights meet or exceed the requirements for the autopatroller group, so they should be trusted with the rights of an autopatroller. This also helps reduce hat collecting. MorganKevinJ(talk) 05:48, 13 November 2019 (UTC)

I think every user in these groups was in the autopatroller group before. (There are maybe just some special cases for GLAM Institutions or WMF staff.) --GPSLeo (talk) 15:20, 13 November 2019 (UTC)

Don't allow LRs to grant Image-reviewer flag[edit]

License reviewers have right to grant Image-reviewer flag, but don't have right to remove it, I believe this is unhelpful and making extra work for sysops. If a LR closes a LRR and grants user the flag then an admin will have to remove redundant AP or patroller flag (Not necessary but most of admins consider removing redundant rights).[1][2][3] In another circumstance: If a License reviewer mistakenly grants someone IR flag then they can't remove it by themselves. We've admins who monitor COM:LRR regularly, so there is no reason for LR to close requests and I've seen requests being closed earlier by LRs. -- CptViraj (📧) 15:33, 13 November 2019 (UTC)

  • Symbol oppose vote.svg Oppose LRs are trusted users. If any mistake occurs, that can be easily dealt with. I don't like excessive controls and regulations which are common among hierarchical organizations. Wikimedia Commons should have self-confidence in its community. 4nn1l2 (talk) 18:37, 13 November 2019 (UTC)
  • Let's think outside the box: Why shouldn't we give LRs the right to remove redundant user-rights? 4nn1l2 (talk) 18:58, 13 November 2019 (UTC)
    Symbol keep vote.svg Agree. We can give license reviewers the right to remove (but not to grant) patroller and/or autopatrolled only when granting license reviewer. License reviewers are trusted and familiar with LR policy , so, why not? Ahmadtalk 20:17, 13 November 2019 (UTC)
  • Symbol oppose vote.svg Oppose Lets try not to find fault with things where there is none. Or, in other words, don't fix what isn't broken. Letting LRs grant the LR flag hasn't hurt anything that I can tell so far. If there are mistakes, which being humans (I'm assuming Face-smile.svg), there will be eventually then that can be easily fixed at that time. Otherwise, lets leave things as they are. As for also granting LRs the ability to remove redundant rights I would also oppose that for the same reason. I never really understood the need to remove redundant rights. If it is noticed when you are already modifying rights so be it but to create a whole new log entry to remove them seems like overkill. There is nothing "extra" you get by having the right twice. A LR/patroller isn't able to "double patrol" something. Giving LRs the ability to remove redundant rights puts on them the responsibility of admin actions (no matter how small that responsibility is). Frankly, I'd perfer to just leave things as they are. --Majora (talk) 21:16, 13 November 2019 (UTC)
    This [removing redundant rights] is, in my opinion, just a housekeeping task. Usually, when one becomes an admin, all their redundant rights (LR, file mover, patroller, rollbacker etc) will be removed. Having them won't break anything and will not give them any extra ability, but we remove them anyways just to keep the logs clean. Ahmadtalk 07:23, 14 November 2019 (UTC)


Add exception to COM:OVERCAT[edit]

In practice, there's an existing exception to COM:OVERCAT (over-categorization) which isn't mentioned in the documentation; I'd like that rectified. It is a fact that nearly all countries have both parent category and top category; for example Category:Dominica has both Category:Countries of the Caribbean (parent county) and Category:Countries of North America (top category). This is true about most countries, and countries should be noted as exceptions to the rule. The practice of doing this has happened not only as it helps the reader navigate Commons, but also as most solid sources state that indeed Dominica is a country in the Caribbean and is also a country in North America. The same exception occurs on Wikipedia. Other countries which have both parent and top category include:

The reasons for the over-categorization rule is to stop 'thousands of images' from appearing in the top category. As we don't have thousands of countries, it doesn't become a problem and therefore the rule is irrelevant; so let's make it an exception to reflect current practice.

I move that we include the wording that 'all countries are exceptions' to COM:OVERCAT (over-categorization). Llywelyn2000 (talk) 08:07, 14 November 2019 (UTC)

Pictogram voting comment.svg Comment The categories you have listed for Ghana, United Kingdom, and Zambia are parallel categories (e.g, both Category:Countries of Africa and Category:East Africa are subcategories of Category:Geography of Africa, not of each other) and don't violate COM:OVERCAT anyway. I don't have a particular opinion on this proposal, but those aren't good examples to justify it. Pi.1415926535 (talk) 08:37, 14 November 2019 (UTC)
Thanks Pi.1415926535. Both are geographical categories; but technically you're correct, because Category:Countries of East Africa doesn't exist, and it should, for consistency, imho, as does Category:Countries of South Asia. But you agree that the categories for India, New Zealand and Pakistan do violate COM:OVERCAT? If so, my suggestion stands. Llywelyn2000 (talk) 08:54, 14 November 2019 (UTC)
Symbol support vote.svg Support - Thinking specifically about countries of the United Kingdom, I can see the benefit of each nation being visible both as Countries of Europe and the United Kingdom as this would aid discoverability of content specific to each country. Jason.nlw (talk) 08:35, 15 November 2019 (UTC)
This can already be solved by adding "**" which would make it look like "United Kingdom (England * Northern Ireland * Scotland * Wales)", but why would a constituent territory of the United Kingdom be considered to be "a country" and not the republics of the Russian Federation or the States (Länder) of Germany and Austria? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 18:56, 17 November 2019 (UTC)
Symbol support vote.svg Support I agree with both Jason and Llywelyn2000. 'Over-categorization', as far as countries are concerned is not a problem (unless at some point in the future, we do have 'thousands' of countries!!!) Really odd too that User:Pi.1415926535 hasn't yet bothered answering Llywelyn's question! It's obvious to all that the categories for India, New Zealand and Pakistan do violate COM:OVERCAT. Cell Danwydd (talk) 20:10, 15 November 2019 (UTC)