Commons:Village pump/Proposals/Archive/2019/05

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Parameter to hide non-US warning on {{PD-US-expired}}

{{PD-US-expired}} has a static warning message that warns "If the work is not a U.S. work, the file must have an additional copyright tag indicating the copyright status in the source country." The message comes with a red warning icon and, in my opinion, always makes it look like something is wrong, even though the warning does not apply if the work was published in the U.S.

Proposal:

  • Add a publication country parameter to the template. If the parameter is provided and set to 'US' or 'USA' (the ISO-3166 country codes for the United States), omit the warning message.

This was also suggested by Xover (talk · contribs) ages ago on the template talk page. BMacZero (talk) 17:48, 11 May 2019 (UTC)

Definitely support this. As well as, I think, some combination of PD-old-*-auto (or is it PD-scan?) that combines US and source country (UK, say), where it still gives that warning even though the non-US license tag is right there; in, from the user's perspective, the same template (I know that's technically not true, but that's what it looks like). And those templates together have both |deathyear= and |location= parameters already, that are just not used for this. --Xover (talk) 18:05, 11 May 2019 (UTC)
@Xover: Yes, I think it's also a good idea to find a way to suppress the warning when a valid license for the source country is provided. BMacZero (talk) 04:45, 13 May 2019 (UTC)
  • @Jarekt: I see what you're getting at, but I think I prefer the country parameter because it requires the user adding it to specifically acknowledge the warning and explicitly specify why it doesn't apply. BMacZero (talk) 04:45, 13 May 2019 (UTC)
  1. many templates could use this parameter and all of them should use the same parameter,
  2. make parameter easy to remember - using | to turn of warnings is not intuitive and will likely require studying of documentation
  3. We might want to turn off warnings in {{PD-US-expired}} for other reasons than publication country being US, for example we already have non US template, like {{PD-Polishsymbol}}
--Jarekt (talk) 10:53, 13 May 2019 (UTC)
Is this perhaps an instance of doing both? To me the semantics of saying "disable this warning (reason unspecified)" and "This was published in country X" (which latter has a side effect of disabling the warning, just as it might, for example, populate a category or something) are different and both would be reasonable things to have. For some simple cases we can in effect compute licensing and copyright status based on date of death (|deathyear=) and place of publication and automatically disable some kinds of warnings (or even enable others). Or if we actually know that some kind of non-US license is provided we can automatically disable anything that is meant to encourage adding one. And then we need a static "Don't show the warning" param for all the cases where such cannot be safely determined automatically for whatever reason. --Xover (talk) 07:53, 14 May 2019 (UTC)
That sounds reasonable to me. BMacZero (talk) 17:44, 15 May 2019 (UTC)

I've made the edit request at Template talk:PD-US-expired#Add_parameters_to_suppress_the_"U.S._work"_warning. – BMacZero (🗩) 03:55, 18 May 2019 (UTC)

(I intend to follow up with another change to allow a non-US license template to be passed, also suppressing the warning, when I have more time. I'm starting with two new parameters here: hide_us_warning and publication_country. – BMacZero (🗩) 04:04, 18 May 2019 (UTC)
I adjusted my edit request to accept another license template like PD-Art (e.g. {{PD-US-expired|PD-France}}). Could @Jarekt: or anyone else interested review my changes so we can get them implemented soon? – BMacZero (🗩) 00:30, 27 May 2019 (UTC)
The edit was made. – BMacZero (🗩) 20:16, 5 June 2019 (UTC)
This section was archived on a request by: – BMacZero (🗩) 20:16, 5 June 2019 (UTC)

Allow operation of bots without a permit subject to a set of rules

Proposal withdrawn, no more votes please. Discussion may continue below.

To stimulate the creation of bots, I propose to reduce the bureaucracy needed to operate one. This will also be useful for users who want to test bots before applying for a permit.

For the purposes of this proposal, a bot is defined as a computer program that will continue editing a wiki without human intervention until the program is halted. So Cat-a-lot and VFC are not bots.

To operate a bot without a permit, it is required to comply with the following:

Account:

  1. The bot must use an account, and the account must have the word "bot" or "robot" in the username. For example: "BotAdventures", "ArchiverBot", "Rotatebot", "Robot power" or "Mike's bot".
  2. The user page of the bot must have the {{Bot}} template at the top and should explain what the bot does.
  3. One bot is not allowed to use multiple accounts.

Requirements:

  1. The edit summary for every edit the bot makes must begin with "Bot: " and contain an informative summary in English. If your bot performs a task aimed at a specific language, the summary is allowed to be in that language instead.
  2. By default, your bot should not mark edits as minor. If an admin requests so, you have to configure your bot to mark edits as minor.
  3. Your bot must have a check to avoid reverting other users within 24 hours if they have reverted your bot. If required to avoid an edit warring bot, you will have to create an internal blacklist for your bot with pages it shouldn't edit. If your bot fights vandalism and reverts edits on purpose, it should perform no more than one revert every five minutes on the same page and never revert an autopatrolled user.
  4. The bot must be internally limited to no more than one edit every 5 seconds per namespace. So one edit in the "User talk" namespace and one in the "File" namespace within 5 seconds would be allowed, but two edits in the "File" namespace within 5 seconds is not allowed. Any administrator is allowed to enforce that with a ratelimit.

Limitations:

  1. Your bot should only make non-controversial edits. If you want to use your bot for potentially controversial edits, you need to seek community consensus first. If you receive any serious complaint, you must pause your bot and discuss. Any admin may temporarily block your bot if concerns are raised.
  2. You are allowed to combine multiple functions or bots in one account, but the account is still not allowed to exceed one edit every 5 seconds. In addition, the edit summary needs to clarify which function or bot made the edit in this case.
  3. You are allowed to operate multiple bots that each have their own account, but only if they are not interconnected or coded similarly in a way that may cause them to fail and start producing bad edits simultaneously.
  4. If your bot messes up, you are expected to repair the damage. How you do this (by hand, using your bot, with VFC, etc) is up to you. Any admin may block your bot as long as it misbehaves.
  5. When you implement a new function in your bot, you are expected to test it before you let it run automatically. If a test run messes anything up, the previous rule applies.

This would be added to Commons:Bots with a new header "Running a bot without permission". - Alexis Jazz ping plz 20:30, 10 May 2019 (UTC)

Allow operation of bots without a permit subject to a set of rules: votes

Proposal withdrawn, no more votes please. Discussion may continue below.

  •  Support, a lower threshold for bot-accounts would probably invite more users to create one, everything above seems sensible. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 07:07, 13 February 2019 (UTC)
  •  Support as proposer. Donald Trung's vote copied per his request. - Alexis Jazz ping plz 20:30, 10 May 2019 (UTC)
  •  Oppose The whole point of a bot flag is to avoid flooding people's watchlists when an authorized bot makes thousands and thousands of edits. If you want to test a bot you can do so in your userspace, no questions asked. Sorry, but allowing unauthorized bots, rules or not, is a horrible idea in my opinion. How exactly are we supposed to rate limit accounts anyways? The only way to stop an account from editing is with a block or an edit filter the latter of which would cause an unnecessary strain on resources. This is an extreme solution to a small problem of "lack of bots" of which was not actually explained. What bot are we specifically lacking that has been requested and not taken up? --Majora (talk) 20:53, 10 May 2019 (UTC)
  •  Oppose The proposal actually introduces stuff that are not actually "rules" at the moment, e.g. not marking trivial housekeeping edits as minor (why?), no multiple functions or bots in one account (huh, that's unnecessary). The benefits are unclear as there is nothing to stop a user doing most of this stuff already if they want to. Set up and account and get on with it is the basic rule, then apply for a bot flag if that's really necessary, like making 100,000 edits in a project. We do not need people to ask for bot flags for simple things like having an account devoted to an upload project, or small scale maintenance stuff equivalent to running VFC on a couple of thousand files that nobody will care about. Want to set up User:AJ_bot and experiment with doing some helpful automated maintenance, nothing stopping you. What we should do is take All bots running on Wikimedia Commons must have advance permission to do so out of the bots policy, it's not the actual norm. --Fæ (talk) 21:32, 10 May 2019 (UTC)
  •  Oppose per Majora. Bad enough when the watchlist is flooded by semi-automated tools (yes, I use these and can understand people's frustration when the watchlist is flooded with category moves for example) but to allow bots without going through the process of getting the bot flag, where we know it isn't unstable (making incorrect moves, removing important information). Bidgee (talk) 01:27, 11 May 2019 (UTC)
  •  Oppose per Majora and Fæ. COM:BOTS exists for a reason; flooded recent changes is not fun.   — Jeff G. ツ please ping or talk to me 09:24, 11 May 2019 (UTC)
  •  Oppose no evidence has been provided that reducing bureaucracy would encourage bot creation.--BevinKacon (talk) 11:45, 11 May 2019 (UTC)
  •  Oppose per Majora and Fæ. Vulphere 13:41, 11 May 2019 (UTC)
  •  Oppose More likely to create problems than reduce supposed bureaucracy. Ammarpad (talk) 18:14, 11 May 2019 (UTC)

Proposal withdrawn, no more votes please. Discussion may continue below.

Allow operation of bots without a permit subject to a set of rules: discussion

@Majora: a ratelimit could be implemented with a new user group. This enforcement doesn't have to be implemented, but if anyone feels it's needed, it could be. You would deal with them the same as users: if they behave well, autopatrol them. Testing bots in userspace is not realistic for many bots, because the File: namespace behaves differently. Your last question: there are many tasks here that could be automated, but it doesn't happen. FlickreviewR for other sites? Dealing with archive.org? In general, many requests at Commons:Bots/Work requests seem to go unanswered if they can't be done with cat-a-lot or VFC. - Alexis Jazz ping plz 21:10, 10 May 2019 (UTC)

The only thing I see on the work requests page that has no responses was posted April 30th. It is the last section on that page. Knowing a little bit about programming and the difficulty of image recognition for computers I'm not sure how feasible that last section even is. As to the suggestion that we would create a new group wouldn't that defeat the purpose of this proposal? And for testing there is the beta cluster or the test server. Two great resources for programmers looking to test things without having to use production. --Majora (talk) 01:07, 11 May 2019 (UTC)
There's more in the archives. The purpose of the proposal is to make it possible for people to create bots without asking for permission when respecting some restrictions. When you must ask for permission, it creates a barrier. You don't need permission to create an account and use VFC or Flickr2Commons.. but if you create a bot that makes 10 edits per day, it may get blocked because the policy says so. The beta cluster, yes, that's a better option. Not everyone knows it exists, but if you do, it's a good option for testing. - Alexis Jazz ping plz 02:15, 11 May 2019 (UTC)

@Fæ: "e.g. not marking trivial housekeeping edits as minor (why?)" Because it's a bot, I suggest not marking anything as minor initially. As soon as an admin sees it and determines it's fine, the admin can ask the bot operator to switch to minor and/or grant the bot autopatrol status.

"no multiple functions or bots in one account (huh, that's unnecessary)" Actually that's specifically allowed?

"Set up and account and get on with it is the basic rule, then apply for a bot flag if that's really necessary, like making 100,000 edits in a project." The basic rule is "set up an account for your bot, get blocked for no reason". Actually VysotskyBot got blocked because "The bot in question is not flaged and therefore flooding the RC with unpatrolled edits." Well, if VysotskyBot misbehaved they should have been blocked for that and otherwise they should have been granted autopatrol. I suppose in this particular case VysotskyBot could have been blocked for having a misleading username or something, but that was not the reason for the block. I agree that "All bots running on Wikimedia Commons must have advance permission to do so" should be removed from the policy. There doesn't seem to be clear support to simply drop that part, so this proposal is an attempt to regulate bots without a permit instead of some wild west scenario. - Alexis Jazz ping plz 23:01, 10 May 2019 (UTC)

The key to these questions is 'non-contentious'. If you set up a general housekeeping account for your projects, it can legitimately do lots of automated and semi-automated things, most of which will be variations of what we do with cat-a-lot or VFC without anyone worrying. This stuff only becomes 'contentious' when categories are flooded, when the automation is very fast and edits are filling recentchanges, or where what is being done causes confusion for others and ought to really have a reasonable amount of community discussion before carrying on.
Over a year there are several rather pointless requests for bot accounts flags where all the user wants to do is some limited housekeeping like uploading 1,000 images or renaming a few thousand files. As a community we should get more in to the habit of encouraging folks to experiment with that type of automation, whether using a legit alternative "bot" account or not, just as if the user were doing the changes using AWB.
Now, rather than worrying about the minor flag, if you think changes need a review, then one can ask on the VP, bots/work or at AN for feedback, or for larger experiments one should consider creating an on-wiki project page to document the project. If these changes are thought by others to be significant automation, then that's a good time to think about creating a long term special bot account for it.
As for the 'one account' question, no there are many, many examples of bot accounts that are generalized and the operator routinely chucks new housekeeping jobs under the same account. There is no need for limited housekeeping jobs to spawn endless new bot accounts. There can and should remain room for common sense.
Naturally, lots of people bang on about regulating bots as if we are under attack by spammers and hackers. This does happen, but making extra bureaucracy for volunteers who want to play around with legitimate automation does absolutely nothing to discourage the fringe black hats and those that get their kick from being annoying. --Fæ (talk) 11:42, 11 May 2019 (UTC)
As for the 'one account' question, no there are many, many examples of bot accounts that are generalized and the operator routinely chucks new housekeeping jobs under the same account. There is no need for limited housekeeping jobs to spawn endless new bot accounts. There can and should remain room for common sense.
Yes, and my rules specifically allowed this, so I don't see the conflict here? I think in general we agree, but somehow we can't figure out the right wording for the policy. - Alexis Jazz ping plz 06:24, 12 May 2019 (UTC)

Removal of interface administrator right due to inactivity

Interface administrators have the right to edit pages that can affect all Commons users like MediaWiki:Common.js. From Commons:Interface administrators:

Editing CSS/JS that gets executed in other users' browsers is very powerful and potentially dangerous in the hands of a malicious user. Interface administrators should be users who need it.

Removal of interface administrator right due to inactivity: votes

Remove the interface administrator right from anyone who hasn't made any edits in 2 months or hasn't made any edits to interface pages in 6 months. They can request it again at any time, no penalty.

Voting closed. 2 months may be a bit too short. I think there should be a some time limit though, so I'll consider a new vote for that. Meanwhile, continue discussion below. - Alexis Jazz ping plz 23:18, 28 May 2019 (UTC)

Removal of interface administrator right due to inactivity: discussion

  • The periods sound very short to me. MediaWiki:Common.js hasn't be edited by *anyone* in more than six months, not sure that we should be encouraging edits on those pages just to keep access going. If they are actively involved with the project in general, and have enough skill to fix problems in those pages to get that access in the first place, that should be enough. And not sure that a two-month break should void access, though I could see a longer break being reason to drop access. On the other hand... if there is no history of being malicious with those edits, I don't see what problems continued access would bring, other than a compromised account. The biggest issue is vetting the access in the first place, I would think. I'm not sure how long an account would need to be dormant for there to be a concern about it being compromised, but there should probably be some limit -- two months sounds awful short though. Carl Lindberg (talk) 16:07, 28 May 2019 (UTC)
@Clindberg: How involved with the project is someone who makes 0 edits for 2 months? (one categorization and you'd be in the clear) Yes, I was away for a while recently. And if I were holding the interface administrator right, it would have been wise to take it away from me. 3 months would also be okay for me. But even so, if someone loses interface administrator after 2 months, all they have to do is ask for it back and a bureaucrat can just give it right back to them.
These interface administrators haven't made any edits in the past 2 months:
And these haven't edited in the MediaWiki namespace for more than 6 months:
  • Ebrahim (no edits in MediaWiki namespace for 10 months)
  • Multichill (no edits in MediaWiki namespace for 11 months)
  • Putnik (no edits in MediaWiki namespace for 7 months)
  • RP88 (no edits in MediaWiki namespace for 8 months)
  • Srittau (no edits in MediaWiki namespace for 9 months)
Some different period can be considered, but I don't think accounts with this right should be allowed to be forgotten and left hanging around. Maybe 3 months (any edit) / 12 months. (MediaWiki edit)- Alexis Jazz ping plz 17:26, 28 May 2019 (UTC)
People take vacations, sometimes long ones. Or maybe shift emphasis to another wiki for a while. That does not really indicate that they are unable to fix interface problems if the need arose. I don't think you have articulated an actual problem with them continuing to have access -- if they were good enough to do it before, they are still good enough to do it. It's really just the risk of a compromised dormant account -- I see no other reason to remove their status. If they get de-admined due to low activity, then remove from this list -- that seems fine. The list you provide above doesn't bother me in the least -- I can't think of a good reason why those users should be removed, especially the list of not editing Mediawiki namespace. That namespace is just not an area which requires frequent editing. Carl Lindberg (talk) 18:35, 28 May 2019 (UTC)
  • @Jeff G.: We have several hat collectors for admins. "De-adminship process as a result of inactivity" is not taking care of it. - Alexis Jazz ping plz 17:26, 28 May 2019 (UTC)
  • @Elcobbola: so we should wait for an account that had little business still being an interface administrator to begin with to be compromised and vote support after that? - Alexis Jazz ping plz 17:26, 28 May 2019 (UTC)
    Even before IA rights were separated from admin toolkit, the account compromises that led to the separation had nothing to do with inactivity. Why do you think it would be otherwise now, that 'inactive' IAs cause compromises and should be eliminated? --Zhuyifei1999 (talk) 21:53, 28 May 2019 (UTC)
    @Zhuyifei1999: They don't cause compromises. Any account could become compromised. So the fewer accounts have interface administrator, the smaller the chance one becomes compromised. So it's better to remove it from accounts that don't need it. If you don't think that's true, why not give IA to every administrator? - Alexis Jazz ping plz 22:39, 28 May 2019 (UTC)
    Compromises are not a matter of chances; it's a matter of bad security practice. This has been true for both major incidents that I am aware of. --Zhuyifei1999 (talk) 01:54, 29 May 2019 (UTC)
  • Presumably because many admins don't know javascript well enough to be editing them -- it is a different skill. The fewer qualified people that have access, the less likely problems will be fixed. I don't have a problem removing people who have effectively left the project altogether, but lack of MediaWiki edits does not indicate that at all, and two months of not editing doesn't mean they aren't active anymore either. If de-admin procedure removes them from this list, that is probably good enough. Carl Lindberg (talk) 22:45, 28 May 2019 (UTC)
    @Clindberg: editing CSS files also requires IA. Also translations that don't require scripting knowledge. If someone hasn't done anything in MediaWiki namespace for, say, a year.. why would they suddenly start contributing to fixing problems? But assuming that's exactly what they want to do, they can ask a bureaucrat and get IA right back. There is no vote or anything complicated: all they have to do is ask. Hell I won't make a problem out of it if they request it every 11 and a half months with a reason good enough for a bureaucrat to grant it while never actually using it. At least they care on some level. Without any period, every time an admin requests IA to perform a few edits, they may remain IA forever, eventually resulting in an accumulation of interface administrators that never use that right. - Alexis Jazz ping plz 23:10, 28 May 2019 (UTC)
    If it's automatic to get re-added, then a compromised account can still cause problems, because the attacker can simply ask first and then go editing once they are re-added. So it would only help with attackers who know mediawiki well enough to damage it with edits, but don't know about the procedure to get re-added to the editing list. If they can perform the task, there really isn't anything that makes them unable to do it a while later. All this would be doing would be adding overhead for bureaucrats and impediments to people who have already been deemed able to make such edits, to me. Honestly, lack of participation is a bigger issue with regular admins, because they are less cognizant of recent history -- the interface part doesn't seem to be that, really but more based on technical abilities in areas that don't change as fast. Carl Lindberg (talk) 00:22, 29 May 2019 (UTC)
This section was archived on a request by: I'll probably create a different proposal for this in the future. - Alexis Jazz ping plz 12:50, 11 June 2019 (UTC)

Sort licence review requests chronologically

The queues of licence review requests are perennially long. In particular Category:License review needed (video) is near 10,000. Yay!

I propose sorting the requests chronologically so that old ones can be reviewed first. Age of a file does matter, because the longer it waits, the more likely its source disappears.

Another advantage is, files uploaded around the same time but starting with different alphabet will be put together. This is helpful for batch uploads.

A disadvantage is, reviewers wont be able to find a particular topic by picking alphabet. (I often jump to U... files because they are mostly related to US and easy for me to review.)

I've proposed this before (Commons:Village_pump/Archive/2019/01#sort_files_pending_review_by_timestamp and Template_talk:LicenseReview/layout-reviewme), but so far only @Ghouston and Jeff G.: were interested to discuss this, so now I make a formal proposal. Do you support sorting by REVISIONTIMESTAMP, or by PAGEID; oppose; or have other suggestions? (You can find the single line of code that implements this proposal at Template_talk:LicenseReview/layout-reviewme.)--Roy17 (talk) 18:30, 9 May 2019 (UTC)

 Support PAGEID. If sorted by timestamp, an edit will send the file to the end of such long queues (thousands of files, i.e. tens of pages of 200 each). However, if queues can be kept short (below 1000), it wont make much difference because even the end of the queue will get reviewed soon enough. (Btw, I dont think padding is essential, since LRR queue is meant to be dealt with shortly, it wont take long for all queuing files to have the same length of PAGEID. Page#9999999 was created in 2010. Right now we are around #78830000. In a few years it will be 9 digits.)--Roy17 (talk) 18:30, 9 May 2019 (UTC)
PAGEID does seem best. Sometimes an old file will be added to the license review queue, and you wouldn't want it to stay at the back forever because it starts with a "9". --ghouston (talk) 02:51, 10 May 2019 (UTC)
 Support PAGEID per nom and ghouston.   — Jeff G. ツ please ping or talk to me 11:28, 10 May 2019 (UTC)
 Support PAGEID as mentioned above. --Yann (talk) 04:58, 12 May 2019 (UTC)
 Support PAGEID as above -- Eatcha (Talk-Page ) 18:53, 12 May 2019 (UTC)
 Support, more things should be organised chronologically, the older the video the larger the chance is that it has been affected by linkrot or a license change. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:12, 12 May 2019 (UTC)
 Support PAGEID. Vulphere 10:16, 16 May 2019 (UTC)

Option to extract date from file name in Upload Wizard

the video I uploaded doesn't contain EXIF metadata to indicate the time of capturing. Instead it is presented in file name, i.e. XXX_20yymmdd_hhmmss.webm. It's a tedious thing to copy-paste them one by one when uploading. And as far as I can say, imaging equipment also uses similar naming scheme by default. So it might be useful to add such an option. Tomskyhaha (talk) 23:59, 18 May 2019 (UTC) p.s. For splitted video files, the last 3 or 2 characters need to be ignored. eg. yymmdd_hhmmss_01. I suddenly realized that, there are so many variations out there, one might just have to write a JavaScript to achieve such function. Tomskyhaha (talk) 00:04, 19 May 2019 (UTC)

Enable convert-to-DR button for everyone

Tracked in Phabricator
Task T227301

According to our deletion policy, when anyone disagrees with the speedy deletion of a particular file, they should "convert to a regular deletion request".

I never quite understood how I was supposed to do that. There were signs that it was possible. Now that I became a filemover, the buttons suddenly appeared! It's part of AjaxQuickDelete, which is enabled by default, but ordinary users don't get DR conversion buttons.

As the policy says anyone who disagrees should convert, I propose we make the "Convert to DR" button available to anyone. - Alexis Jazz ping plz 15:48, 25 May 2019 (UTC)

Enable convert-to-DR button for everyone: votes

Enable convert-to-DR button for everyone: discussion

Discuss details for this proposal here.

I was perplexed why many people were obviously using some kind of script that converted the thing but I could not see the button. Why was it reserved for filemovers? It should be enabled for all autopatrollers.--Roy17 (talk) 17:21, 11 June 2019 (UTC)
{{LangSwitch|en='''Challenge speedy deletion'''<br>start a regular deletion request/discussion instead|nl='''Maak bezwaar tegen directe verwijdering<br>start een regulier verwijderingsverzoek/discussie|zh|zh-hant|yue=反對快速刪除<br>改提刪除討論}}
Rillke also suggested not to make the "remove this tag" available for everyone, and I agree. Wasn't part of the proposal either. - Alexis Jazz ping plz 11:38, 12 July 2019 (UTC)
All of those changes seem reasonable to me. Kaldari (talk) 11:41, 12 July 2019 (UTC)
I added Chinese translations to Alexis Jazz's code. It means oppose speedy deletion, change to deletion discussion.--Roy17 (talk) 17:21, 13 July 2019 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2019/05&oldid=361777167"