Commons:Village pump/Proposals/Archive/2020/01

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Archive This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

File use in OpenStreetMap and addition to scope

Hi, I have recently started a pet project of documenting all shelters and huts in Sweden. There are about ~4000 in total now in the database and only a handfull link to Commons. I wonder if it would be a good idea for you to implement a solution to mark all photos/categories linked from OpenStreetMap in here? I'm sure a bot could parse the feed from the planet.osm file and update the relevant pages. Currently the use of commons looks like this:

@count	@count:nodes	@count:ways	@count:relations
20645	10327	        8900     	1418

Additionally could it be added to the COM:SCOPE also that files that is valuable to OpenStreetMap is in scope? WDYT?--So9q (talk) 10:39, 16 January 2020 (UTC)

Have you consdiered creating a Wikidata item for each, and using the images there, also? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:15, 16 January 2020 (UTC)
Yes, unfortunately because of license restrictions this is not possible for all of them. About 80% of them have coordinates also on a Swedisch government CC0 map, but the rest is surveyed by individuals. Unfortunately there is a lack of tools for me to both find and effectively communicate with these individuals.--So9q (talk) 14:52, 16 January 2020 (UTC)

Patrol all old edits of now autopatrolled users

If users get the autopatroll rights all edits made before stay unpatrolled. This lets them shown up when parolling older edits. As only users they made good edits in the past and can be trusted in the future should get these rights I would propose that a bot (as there is no MediaWiki feature for this) should patrol all old edits made by new autopatrolled users. --GPSLeo (talk) 11:52, 2 January 2020 (UTC)

Symbol support vote.svg Support at least patrolling all edits that are less than a month old. Perhaps some option to ping the bot to patrol the rest? - Alexis Jazz ping plz 13:19, 2 January 2020 (UTC)
Edits older then a month become marked a patrolled by MediaWiki. I think looking for rights changes log once or maybe two times a day would be fast enough. --GPSLeo (talk) 13:25, 2 January 2020 (UTC)
  • Symbol support vote.svg Support Please also patrol deleted edits, If I had time I maybe would like to work on patrolling deleted edits. -- Eatcha (talk) 17:01, 2 January 2020 (UTC)
  • Symbol support vote.svg Support, most users don't become autopatrolled after a couple of months and most edits that need patrolling by new users are made within their first months/moments (depending on how quickly someone integrates / learns to adapt to Wikimedia Commons). An admin wouldn't grant this user right to a user unless they are certain that they are trustworthy, so while an argument can be made that not all edits are always good by autopatrolled users (this is evidenced by the large number of deletion requests on "User talk:Russavia"), the patrol backlog is huge and would benefit from this. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 06:47, 3 January 2020 (UTC)
  • Symbol support vote.svg Support Having an endless stream of unpatrolled edits that are very likely acceptable makes patrolling more difficult. —Justin (koavf)TCM 07:54, 3 January 2020 (UTC)
  • Symbol support vote.svg Support: Good idea, This will help to reduce the patrol backlog. -- CptViraj (📧) 07:58, 3 January 2020 (UTC)
  • Symbol support vote.svg Support: It’s logical. -- Tuválkin 22:58, 3 January 2020 (UTC)
  • Symbol support vote.svg Support - Makes sense. Edits older than 30 days automatically expire from the unpatrolled queue. I think autopatrolled users should have standard edits in the month before the right is granted to their account, so there should be no real problems in my opinion. Ahmadtalk 17:23, 15 January 2020 (UTC)
  • Symbol oppose vote.svg Oppose I think this shouldn't be done automatically and for every case. It may well be that a user is now autopatrolled but 4 weeks ago he was not experienced enough and made mistakes. Just patrolling these edits by bot doesn't help, either they are not visible anywhere, then it doesn't make any change and should not be done, or the edits should be manually checked. --Krd 15:52, 16 January 2020 (UTC)
@Krd: any examples of a user who was made autopatrolled while having edits less than a month old that require patrolling? Generally, having edits that require patrolling less than a month old is a red flag for giving anyone autopatrol. - Alexis Jazz ping plz 18:35, 17 January 2020 (UTC)

better svg rendering (less rendering bugs and more supported svg-features)

According to phab:T40010#4443760 resvg not only renders better than the rsvg, resvg is even faster in bechmarks

Program render time Tests passed
resvg 150 s (best) 221
rsvg 2.42.2 242 s 202 (worst)
Inkscape 0.92.2 1610 s 257
Batik 1.9 3686 s 254

Older bechmarks can be found on

@Glrx: conclued in 2019: "I'd go for a trial."

resvg is developing much faster than rsvg. My personal experience is that RazrFalcon (developer of resvg) repairs reported bugs (in svgcleaner) faster than scour, svgo, phab:, librsvg and even inkscape.

In the current (2020) Support-table of RazrFalcon rsvg is even better than the svg-rendering of Firefox and Chrome. Firefox and Chrome are often considered as almost perfect.

I propose to change the svg-renderer to resvg (instead of rsvg).

Extended content

In phab:T40010 (Re-evaluate librsvg as SVG renderer on Wikimedia wikis) one realistic alternative to librsvg (the current buggy svg-renderer of Wikimedia) was found: resvg

I know Pictures showing a librsvg bug and Librsvg_bugs very well. I think I contributed most workarounds in Pictures showing a librsvg bug (overwritten with a workaround) and Pictures showing a librsvg bug (SVG replaced). I consider libsvg as a pain in the ass. I consider Bugs such as phab:T11420 (text along a curved text not supported) or phab:T35245(multipe x-koordinates for letters in text not supported) are a severe problem. phab:T36947 (bad text aligment on small font-sizes) is the most mentioned problem by different users on. Check e.g. :en:Wikipedia:SVG_help#(librsvgbug) and the following two questions. (three times after each other by three different users, were astonished by the same rsvg-bug)

Because of the bad rendeirng of rsvg compared to common Browser there were even the epic task: phab:T5593 ([Epic] SVG client side rendering) and the whish to render svgs by browser meta:Community_Wishlist_Survey_2019/Archive/Option_to_embed_SVGs_as_SVGs (closed before voting because would have been too big), which are more problematic since securityissues and you can't ensure uniform rendering. resvg is in some benchmarks even better than the best Browser renderer, therefore we should go for it.

 — Johannes Kalliauer - Talk | Contributions 21:48, 3 January 2020 (UTC)

Mmmh, I thought I had already written something here a while ago … Anyway, @JoKalliauer: I think the reason you're not getting much feedback here is that this is a highly technical topic. Very few of us "regular" people here are in the position to judge whether the switch would be a good idea as we have nothing to build our opinion on. We all know that our current way of rendering SVG has issues, and I don't think anyone here would be opposed to a better solution, but we don't really have a way of estimating the risks associated with a switch to resvg. After skimming through the taks at Phabricator, it seems like most of the potential issues have been sorted out. @Glrx: was very critical in the beginning and seems to be convinced now that it would be a good idea to "go for a trial" (although it's unclear to me what kind of trial that would be). If the developers want community feedback before going live with this, I guess we'd need a test version on a beta server so we can compare the results and look for issues. If that's not necessary because there's no doubt that resvg is the best choice anyway, then there's no need to ask for "permission" from the community. All I can offer you right now is a big fat Symbol support vote.svg moral support – SVG support is something that could really use some improvements. --El Grafo (talk) 13:41, 27 January 2020 (UTC)
moved to phab:T243893  — Johannes Kalliauer - Talk | Contributions 19:51, 20 February 2020 (UTC)
This section was archived on a request by:  — Johannes Kalliauer - Talk | Contributions 19:51, 20 February 2020 (UTC)

Specifying categorizing by file format

After discussion here (Commons:Administrators'_noticeboard#Massive upmerging and deletion) user:Themightyquill gave the proposal to specify Commons:Categories policy related to categorizing by file format. The proposal is:

--Estopedist1 (talk) 06:29, 28 January 2020 (UTC)

  • I am not against this, but I do not like this. I already think that we have lots of "Intersection categories" which should be done by other tools. We currently can intersect categories with search, open up a search and in advanced put in multiple categories like so. However, this is non-trivial and is error prone. But doing it all by hand will create another level of problems. You already have huge trees of categories by subject, we will basically duplicate them all by file type. We also have huge trees (where I am trying to help out right now) by date. Currently I am trying not to touch countries which are sometimes written with the and sometimes without. It is a horrible mess and any change leads upwards. But if we will also have to propagate any change horizontally into intersections... I pitty whomever will this task fall upon. What we do need is a tool to allow users to intersect easily and quickly. ℺ Gone Postal ( ) 06:49, 28 January 2020 (UTC)
@Gone Postal: you are the information visionary like I would like to be. This proposal is essential step to clean our category tree and to get rid of eg category:JPG flags by country, category:PNG flags by country, category:Ogg files of classical music for piano--Estopedist1 (talk) 14:44, 29 January 2020 (UTC)
@Estopedist1: Wow, thanks for the compliment :) I do not, howewever, think that abondoning these categories will happen now. And until we get good tools (not external ones that take several seconds to complete for your to realise that they return wrong results, and not something where you have to write an SQL-like query) we will be unable to abandon these categories. ℺ Gone Postal ( ) 18:52, 29 January 2020 (UTC)

FastCCI - Enhancement - Only images from Wikidata

To have a new option that only selects images that are on wikidata. This would allow to obtain only one/better/more representative image of each category (within a given parent category) without overloading the browsers memory (which is one of the big problems for many users)--JotaCartas (talk) 01:06, 31 January 2020 (UTC)

Definition of educational

There are objects with many thousands pictures of them and a huge amount of these images has an acceptable or good quality. But it would be difficult to find an educational use where this many images are needed. And no one would forbid to upload now images of these object and none of these images gets deleted because it is just one with many similar ones. The current policy says that images are in scope if they are used in an other Wikimedia project or if they can be used for educational purposes. Educational is defined as "providing knowledge; instructional or informative".
To have many pictures of one object in scope I would propose to add "showing the real world with every detail" to the definition of educational. I think that would include many images of the same subject in the scope while preventing mass upload of fictional or promotional content. Of course this should also not include media violating the human rights of someone. --GPSLeo (talk) 20:48, 28 January 2020 (UTC)

By default the Vulcan philosophy of Infinite Diversity in Infinite Combinations has applied.
It's already sort of in the policies, though guidelines can always improve their wording. -- (talk) 20:57, 28 January 2020 (UTC)
I disagree; "showing the real world with every detail" is already part of educational use. Showing hundreds of largely similar images of the Tower Bridge (which I'm guessing this is in response to) is not showing unique details of anything, and I'd argue we should be pushing back at new uploads of the same object in the same way. A thousand pictures of the Tower Bridge, each mostly not overlapping, showing the Bridge at detail you can't get from File:Tower Bridge from Shad Thames.jpg would be awesome, and I don't think anyone would object to that.
Basically, I don't think the rule adds anything at all, and while it appears to me to be about a subject on which you and I disagree, I don't think it clarifies the disagreement for the larger audience. (I'd also say it's largely moot; nobody, including me, is rushing to delete files from those categories I complained about.)--Prosfilaes (talk) 21:31, 28 January 2020 (UTC)
I also do not think that this would make any major change, but with this words some misunderstandings and ambiguities of educational and the project scope could be eliminated. I would disagree that there are enough images of some objects. I see no reason that we can not store a huge amount of images, storage is not very expensive. One example that images where it looks like there is no use for them can have a use case: I used File:Silberteich 18.jpg and File:Silberteich 19.jpg to find the exact location of the WLE finalist File:Silberteich.jpg. --GPSLeo (talk) 11:04, 29 January 2020 (UTC)
If we're going to toss the flood gates open, why not start with ceasing to delete photos people upload of themselves and their bands and the like? That's contentious and frustrating to the uploaders, and they can be neatly stuck away in the category tree and forgotten at little cost.
One of my hiking buddies complained that one of his friends would post photos of their hiking trips, but instead of a selected few, he'd post 300+ images, making them extremely tedious to go through. When I'm in the mood, I can rack up hundreds of photos in a couple days. If I uploaded them all, I think it worsen the quality of Commons, make it harder to find useful images. I have hundreds of pictures of the desert cottontail; I've uploaded one, not great quality, video, because it's the only video on Commons where you can actually see how the cottontail moves. And if I were to encourage myself and others, it would not be to upload the same tourist pictures; a picture of a local park, as of yet undocumented on Commons, is worth way more than another of the Tower Bridge.--Prosfilaes (talk) 21:41, 29 January 2020 (UTC)
As I sad there are use cases for many pictures of the same. For finding the best for most common uses we should better look on improving the quality image assessment procedures. --GPSLeo (talk) 09:30, 30 January 2020 (UTC)
I think the adding mediocre, poorly categorized images quickly overwhelms the value of any of those use cases. It takes work to handle them.--Prosfilaes (talk) 01:13, 7 February 2020 (UTC)
If I may add a further opinion: I do agree with Prosfilaes that for objects where we already have hundreds or thousands of highly similar and redundant images, adding even more should be discouraged unless new ones are in some aspect of superior quality or show previously-unseen details. Similarly, I believe that deleting redundant images does serve a purpose. Among hundreds or thousands of images showing the same object, naturally some will be of better, others of worse quality. Now, if an article editor or any other user is in need of an image, having to look through an endless number of images just to find the better ones is difficult and highly time-consuming. On the other hand, if redundant images are continuously sorted out, with inferior ones being deleted and the better ones kept, it is far more easy to find the images that one actually wants to see. GFJ (talk) 19:33, 29 January 2020 (UTC)
There's another option between ignoring and deleting, which I'd call curating. E.g., pick the best photos of the tower bridge, from various observation points and weather conditions. Then put {{Superseded}} on any inferior image that matches one of these, and put all such images in a "superseded" subcategory. --ghouston (talk) 02:50, 30 January 2020 (UTC)
The curation used to be on galleries, not in categories. Pick the best handful of images to illustrate a subject and put them in a gallery. Entry points to topics should prefer the galleries, if we go that route. Other than potentially having different links from Wikidata, seems like that should be just as easy (if not easier) than curating categories. Carl Lindberg (talk) 03:55, 31 January 2020 (UTC)
  • I think that this is a solution to a small problem, which will have serious negative consequences. Here is a hypothetical educational useage: I want to illustrate the difference of winter weather in some village. What I am searching for (in this hypothetical) is an outside photo of any objects that was made in December of each year. Your approach would delete many such photos, simply because the objects on them are already illustrated elsewhere, but I was not searching for those objects, I was looking at everything around them (is there snow, how much of it, what kind of snow, etc). So by trying to make it slightly easier for a user to find a good image, you have just made it completely impossible (unless the user is an admin and is able to look at deleted images, but then they have lost all their categorisation, etc). On that ground I am in Symbol oppose vote oversat.svg  strong opposition to this proposal. ℺ Gone Postal ( ) 05:39, 7 February 2020 (UTC)
I don't think anyone suggested deleting images that are not actually redundant, such as images that show the same object, but in different seasons/backgrounds/landscapes. The image of a village in summer is certainly not redundant to an image of the same village in winter and both should absolutely be kept, I very much agree with you there. Where I believe that deletions are useful is only with "real" redundancy. If we already have 20 images of an object in the same season, with the same background (including general weather, vegetation, etc.), then we don't need 20 more. In this scenario, with real redundancy that takes backgrounds, etc. into account, deleting inferior images is highly useful. GFJ (talk) 20:17, 7 February 2020 (UTC)
Ok, I have typed an answer, and then deleted it. As it stands, I do not believe that this is a constructive proposal, and your response actually points to the problem with it. Anybody who will want to delete a file will say "Yes, of course we allow all educational media here, but this is a 'real' duplicate." We already have a policy about deleting scaled down duplicates, and everything else is the step in the wrong direction. ℺ Gone Postal ( ) 20:50, 7 February 2020 (UTC)
Have a look at Category:ZooSphere Gymnopleurus sericeifrons. These are my uploads, I think none is redundant, but they all have the same background and every photograph is one of a large set of exactly the same insect. -- (talk) 10:05, 19 February 2020 (UTC)
Once again, this appears to boil down to how one defines "redundancy". The images from the above category indeed show the same dung beetle, but from different angles, thereby highlighting different details. Like you, I would not consider such images redundant. If the angles were the same, then yes - but that's not the case. Obviously, exhaustively defining "redundancy" is nearly impossible and also not very helpful, different users will always have different criteria for what they consider redundant. Luckily, with Commons:DR we do have a system for peer review. I am not in favor of this proposal. What I do want to achieve with my comments is to make the point that even if it may not be too often, there indeed can be cases where non-identical images are so redundant that deletions become useful to make it easier to find the actually good ones. However, as said before, the threshold for redundancy must of course be high. Here's an example: would most of you say that this image is redundant to this one, but of significantly lower quality? GFJ (talk) 12:45, 19 February 2020 (UTC)
WRT example, no they are not redundant. Both are a bit pants if the intention is to illustrate the game though. -- (talk) 12:49, 19 February 2020 (UTC)