Commons:Village pump/Proposals

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

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; the latest archive is Commons:Village pump/Proposals/Archive/2024/10.

COMMONS DISCUSSION PAGES
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?

 

Start a new discussion

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

CAPTCHA for many IP edits

[edit]

There is a new feature that allows AbuseFilters to require a CAPTCHA before uploading an edit. I would like to enable this for many IP edits, especially IP edits on mobile. The aim of this is to reduce the huge amount of accidental and nonsense edits. Are there any concerns against this? GPSLeo (talk) 10:06, 18 August 2024 (UTC)[reply]

No, it would be good to reduce maintenance time to free up time for other tasks. However, I doubt this is enough and have called for better vandalism/nonsense-edit detection like ClueBot does it on Wikipedia here which may also be some context for this thread. Prototyperspective (talk) 10:25, 18 August 2024 (UTC)[reply]
Detection of nonsense after is was published is not our problem, this is possible with current filters. We do not have enough people looking on the filter hits and reverting the vandalism. We therefore need measures to reduce such edits. If we do not find a way to handle this we need to block IP edits entirely. GPSLeo (talk) 10:56, 18 August 2024 (UTC)[reply]
I think we rather need measure to automatically revert such edits. Detection is a problem if it's not accurate enough that it contains too many false-positives that people don't implement them. The proposal is not just about detection but also about what follows from there – for example one could also automatically revert them but add the edit to a queue to check in case the revert is unwarranted. Prototyperspective (talk) 11:00, 18 August 2024 (UTC)[reply]
We might to want to experiment mw:Moderator Tools/Automoderator. It won't probably work perfectly at a first experiment, but we will at least know some indication of where it works and where it doesn't. whym (talk) 01:18, 1 September 2024 (UTC)[reply]
Very interesting! Thanks for the link, it's very constructive and if possible please let me know when WMC enables this or when there is some discussion about enabling it.
It could save people a lot of time and keep content here more reliable/higher quality. I think there's not even auto-detection for when e.g. 80% of a user's edit have been reverted for checking the remainder and whether further action is due. Prototyperspective (talk) 23:18, 1 September 2024 (UTC)[reply]
I think we rather need measure to automatically revert such edits Absolutely yes. I think the risk of losing well-intentioned IP edits in Commons is quite low (for example, I had edited Wikipedia as an IP user many times before I registered, but I've never thought of editing Commons as an IP user). MGeog2022 (talk) 21:27, 26 September 2024 (UTC)[reply]
Capchas are supposed to stop robots from spamming, right? Why would this stop some random human IP user from posting “amogus sussy balls”? Dronebogus (talk) 14:05, 18 August 2024 (UTC)[reply]
Seconding this. CAPTCHAs should only be used to prevent automated edits, not as a means of "hazing" users making low-effort manual edits. Omphalographer (talk) 20:12, 18 August 2024 (UTC)[reply]
Maybe candidates could be edits that are currently fully blocked but have some false positives that could be let through?
 ∞∞ Enhancing999 (talk) 13:59, 27 August 2024 (UTC)[reply]
You did not consider the full rationale of OP, he wrote huge amount of accidental […] edits and this measure would be partly and probably mainly be about greatly reducing accidental edits. OP however failed to name some concrete specific examples which have been brought up in a thread elsewhere. I favor better detection of nonsense edits and automatic reverting of them but requiring captchas for IP edits on mobile or for certain actions may still be worth testing for a month or two to see whether it actually reduces these kinds of edits. Prototyperspective (talk) 16:43, 27 August 2024 (UTC)[reply]
I'd totally support requiring captcha's for edits on mobile in general, not just for IP addresses. I know personally I make a lot of editing mistakes on mobile just because of how clanky the interface is. There's also been plenty of instances where I've seen pretty well established users forgot to sign their names or make other basic mistakes on mobile. So I think having captcha's on mobile for everyone would be a really good idea. --Adamant1 (talk) 17:59, 27 August 2024 (UTC)[reply]
In Special:Preferences there is an option "Prompt me when entering a blank edit summary (or the default undo summary)". Enabling this seems like a good way to provide a chance to briefly stop and review what you are trying to do. I wonder if it's possible to enable it by default. A captcha answer has no productive value, but a good edit summary will do. whym (talk) 01:15, 1 September 2024 (UTC)[reply]
I'd support that as long as there's a way for normal, logged in users to disable it if they want to. I think any kind of buffer between making an edit and posting it would reduce bad edits though. Even ones that are clearly trolling. A lot of people won't waste their time if they have to take an extra step to post a message even if it's something like writing an edit summary. --Adamant1 (talk) 01:34, 1 September 2024 (UTC)[reply]
There is something to be said for en:WP:PBAGDSWCBY and en:WP:ROPE (I know, we don't ban here, just substitute indef for ban).   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 02:01, 1 September 2024 (UTC)[reply]
@Jeff G.: True. That's one of the main reasons I support requiring people to have an account since it seems to be much easier to track and ban editors that way. --Adamant1 (talk) 02:05, 1 September 2024 (UTC)[reply]
@Adamant1: Like it or not, we still have "anyone can contribute" right on the main page.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 02:17, 1 September 2024 (UTC)[reply]
@Jeff G.: Anyone can still contribute if we require accounts. I could see not requiring accounts if there was legitimate reason for it, but I've put a lot of thought into this over the last couple of years and can't think of one single legitimate reason why someone wouldn't be able to create one. We'll have to agree to disagree though. I can understand why they let IP edit Wikiprojects back in the day though, but the internet and people are just different now and the project should be able to adapt to the times. --Adamant1 (talk) 02:21, 1 September 2024 (UTC)[reply]
This does not help in cases this is about as theses types of edits always have auto generated edit summaries and no way to edit the edit summary. GPSLeo (talk) 04:32, 1 September 2024 (UTC)[reply]
Maybe that is a software problem to be fixed? It already says "(or the default undo summary)" after all. Reminding users to add a bit more to what's auto-generated seems like a natural extension. whym (talk) 18:54, 1 September 2024 (UTC)[reply]
The Wikibase UI does not have such a feature and in the many years of Wikidata it was not considered a problem that changing the edit summary is not possible. GPSLeo (talk) 20:24, 1 September 2024 (UTC)[reply]
Can Commons customize that in their Wikibase instance? It's not yet implemented in the Wikidata UI, but on the API level Wikibase supports edit summaries according to d:Help:Edit summary. whym (talk) 23:38, 1 September 2024 (UTC)[reply]
I make much fewer editing mistakes on mobile when I use my new portable bluetooth mini keyboard. Touch-typing in the dark, however, can still be problematic.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:52, 1 September 2024 (UTC)[reply]

One week test

[edit]

There is definitely no consensus to use this feature for now but there were some people suggesting to make a test. Therefore I would propose that we make a one week test and then evaluate the results. GPSLeo (talk) 19:37, 2 September 2024 (UTC)[reply]

Why? How is that useful? No consensus to implement means no consensus to implement, period. I can guarantee it will not gain any more consensus with a test version. Dronebogus (talk) 21:08, 2 September 2024 (UTC)[reply]
There were some people suggesting to make a test. There is also no consensus against some kind of measure. GPSLeo (talk) 14:11, 3 September 2024 (UTC)[reply]
There is also no consensus for it. I feel like you’re just projecting whatever you like onto the discussion to make sure your proposal gets through somehow. It sucks when people don’t like your idea, but “seeing” consensus where none exists is not the way to fix that Dronebogus (talk) 19:54, 3 September 2024 (UTC)[reply]
 Oppose. As I noted above, this is not an appropriate use of CAPTCHAs - their purpose is to prevent automated edits by unauthorized bots, not to prevent "accidental or nonsense edits". Omphalographer (talk) 20:42, 3 September 2024 (UTC)[reply]

Simple edit confirmation

[edit]

Instead of a CAPTCHA it is also possible to show a warning and require the user to confirm their edit. I would propose to make a one week test where we show IPs a warning "You are publicly editing the content of the page." and they have to hit the publish button again but with no CAPTCHA. GPSLeo (talk) 15:59, 26 September 2024 (UTC)[reply]

 Support Makes more sense. I think it's worth giving that a try but one week is short so somebody would need to have a good way of tracking relevant changes and creating some stats to see whether it's been effective. Or are there any better ideas what to do about Unregistered or new users often moving captions to other languages? Prototyperspective (talk) 20:58, 26 September 2024 (UTC)[reply]
 Support A month is probably better though. --Adamant1 (talk) 21:05, 26 September 2024 (UTC)[reply]
I suggest the warning message includes a link to a place where users can give feedback (complain) so that we might see how many users are affected; and the test period be 1 month. 1 week is too short. collect stats over the period as often as possible (daily?). RoyZuo (talk) 06:34, 18 October 2024 (UTC)[reply]
For the monitoring I created a tool [1]. The feedback is a problem as we had to protect all regular feedback pages due to massive vandalism and I think if we create a new page for this we would have to monitor it 24/7 and massively revert vandalism. GPSLeo (talk) 08:27, 18 October 2024 (UTC)[reply]
Interesting tool. Please correct the typo in the page title and add a link to some wikipage about it (where is the software code, where to report issues or discuss it, is it CCBY). It does show edits that were later reverted in the charts and not edits that are reverts by date right? Prototyperspective (talk) 11:03, 18 October 2024 (UTC)[reply]
I created a documentation page for the tool Commons:Revert and patrol monitoring. GPSLeo (talk) 11:01, 19 October 2024 (UTC)[reply]
Can you keep the data from start to now, instead of only 1 month? RoyZuo (talk) 18:16, 20 October 2024 (UTC)[reply]
The problem is that all edits become marked as patrolled after 30 days. It would be possible to also check the patrol log to get this data but it would be a bit complicated and would require to much API request for daily updates. For edit counts and revert counts it is not such a huge problem but also a bit problematic when requesting data for a hole year every day as edits might get reverted after a year. GPSLeo (talk) 18:40, 20 October 2024 (UTC)[reply]
You could just keep the data as it was right before all edits become patrolled, right? RoyZuo (talk) 14:00, 23 October 2024 (UTC)[reply]
When i first looked at the table data was starting from 2024-09-17. now you can keep instead of erasing data that "expire" after 1 month. RoyZuo (talk) 14:04, 23 October 2024 (UTC)[reply]
You mean just keeping the row in the table without updating the number of reverted edits? GPSLeo (talk) 14:43, 23 October 2024 (UTC)[reply]
From now on I will keep the data from the last day without updating it. In two month I will then need to update the design of the page, maybe I make a sub page for the archive data. GPSLeo (talk) 16:04, 25 October 2024 (UTC)[reply]
The feedback page is about this specific measure (double confirmation). it can be temporary, so that any existing users have a central page to complain. imagine if you always edit without login, suddenly this double confirmation kicks in and you get frustrated. you want to complain, but dont know where. so if we have a link for them to write something, and if anyone of them bothers to do, we can see how many are affected and why, etc.
once the measure becomes permanent, users should just take it as it is; no point in complaining. RoyZuo (talk) 11:51, 18 October 2024 (UTC)[reply]
We can give it a try. GPSLeo (talk) 10:30, 19 October 2024 (UTC)[reply]
I just added the regular abuse filter error reporting link with a different text. GPSLeo (talk) 16:01, 25 October 2024 (UTC)[reply]

Almost everyone hit with this filter is a registered users with a Wikimedia SUL account, it's I barely see any unregistered users being warned at all... --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:34, 27 October 2024 (UTC)[reply]

Fixed now. I accidentally had an OR and not an AND between anon and mobile condition. GPSLeo (talk) 16:57, 27 October 2024 (UTC)[reply]
Do you think you could make it work better for "new external links" edits? Every time those happen (often when I'm NOT attempting to add an external link), I have to put in a different CAPTCHA twice for the same edit. 2603:3021:3A96:0:4E4:95C6:BC81:D2E1 21:31, 28 October 2024 (UTC)[reply]
If you get a CAPTCHA you triggered another anti spam mechanism that has nothing to do with AbuseFilters. GPSLeo (talk) 22:08, 28 October 2024 (UTC)[reply]

First results

[edit]

After one week I looked at the share of reverted edits compared to all edits and it shows a huge decrease of reverted edits while the number of edits only decreased slightly [2]. When looking at the filter hits it also shows that many nonsense edits were not sent while most useful edits were confirmed. GPSLeo (talk) 08:05, 3 November 2024 (UTC)[reply]

@GPSLeo from when to when was the filter live? RoyZuo (talk) 18:09, 14 November 2024 (UTC)[reply]
The filter with current settings was activated on 16:55, 27 October 2024 and is still active. As there were no complaints I would just leave it on as it seems to have at least a small positive effect. GPSLeo (talk) 19:47, 14 November 2024 (UTC)[reply]
The graphs dont look much different before or after 27 October. ip users just happily keep on editing by tapping twice? if true that sounds like very stubborn ip users. RoyZuo (talk) 20:49, 24 November 2024 (UTC)[reply]

Global Folk Music Collection (with Wikidata)

[edit]

Dear all,

This is a very initial idea of a project to Wikimedia Commons. Let's call in "Global Folk Music Collection" (GFMC). A lot of folk music is copyright free, often marked as "trad." Among the folk musicians it is common to consider that also "new" folk music, based on traditional music, should be free and libre — by people for people.

To document and maintain this kind of intangible cultural heritage is hardly done by anyone. UNESCO is interested in this, but I do not see that they will get anything done in this field at any time soon.

Could Wikimedia Commons have a GFMC, with semantic web features, so that one could browse and search it with various properties? In the Wikidata there is the WikiProject Music and Track properties. To serve the CFMC, there should be more properties, such as location, cultural environment, instruments etc.

How would this then work from the editor user's point of view:

  1. I walk in Dublin and hear some very cool pipe playing by a street musician.
  2. I ask the musician, may I record it and share it online.
  3. The musician say yes, but asks me to share it with his name name.
  4. I got to Wikimedia Commons and share the recording to the GFMC.
  5. Later my friends, a musicologist, will describe it with the properties.

How would this then work from the reader user's point of view:

  1. I got to Wikimedia Commons and search for "Irish Folk pipe music".
  2. I'll find the pipe recording made in Dublin.
  3. I check the metadata and the GFMC-portal and find more folk music.

From here you may replace "Dublin" with "Lagos" or whatever.

Some national libraries also have collections of folk songs and sounds samples of traditional instruments. I assume they could be interested in to share their content to the GFMC, too.

One technical thing that might be missing at the moment is universal identifier of music samples / songs. Spotify etc have their own but not free /libre identifier. Maybe this is more WikiData -thing, but could be something the Wikimedia Commons community could work together with the WikiData, wizards.

Peace,

- Teemu (talk) 11:57, 17 October 2024 (UTC)[reply]

  • @Teemu: What does the first "C" stand for in CFMC? Obviously not "Global". - Jmabel ! talk 19:47, 17 October 2024 (UTC)[reply]
    Typo. I'll edit. Teemu (talk) 15:45, 19 October 2024 (UTC)[reply]
  • The process you describe "from the editor user's point of view" does not even approach Commons standards for a release by the piper. The piper owns copyright on his or her performance; oral communication to one person is not by any means sufficient documentation of a free license. Compare COM:VRT. - Jmabel ! talk 19:57, 17 October 2024 (UTC)[reply]
    Fair enough. How about having in your phone (the recording device) a form/contract where the piper signs with her finger to gives it for commons under free licence?
    With a team, we are considering to build an app for the purpose and considering where the audios should be stored. Do you think Commons would not be a good place for this? Teemu (talk) 15:52, 19 October 2024 (UTC)[reply]
  • In my experience, most "folk" performers have little idea of the copyright status of works they perform. To take two famous examples:
    1. The Carter Family recorded "Wildwood Flower" thinking it was a traditional Appalachian song. It was not: it was a parlor song from about 50 years earlier, still in copyright at the time (though not now). BTW, somewhere along the way someone had misunderstood a lyric, and "the pale oleander" had become "the pale and the leader".
    2. The Weavers recorded "Wimoweh", thinking it was a South African folk song. It was not: it was a South African pop song, barely a decade old at the time. It took a long time for the songwriter to get any of their rights restored.
This is potentially a problem for anyone doing field recordings of material where they do not themselves know the background in any detail. - Jmabel ! talk 20:04, 17 October 2024 (UTC)[reply]
True. What would be a solution to solve the challenge? Teemu (talk) 15:53, 19 October 2024 (UTC)[reply]
I guess what I'm saying is that Commons may not be the most suitable venue to gather primary source materials with potentially complex copyright issues.
In your example above about "a form/contract where the piper signs with her finger", do you really think that is informed consent, suitable for a contractual waiver of rights? I sure don't. Oral culture materials gathered casually on the street are always going to be tricky in terms of rights. I think you'd do really well to look closely into academic protocols around consent for such materials before trying to propose something here. - Jmabel ! talk 13:01, 20 October 2024 (UTC)[reply]
Dear @Jmabel I am very aware of informed consent practices in social science and humanities and research ethics in academic context in general. I am truly sorry if my proposal hurt your feelings. Thank you for your feedback. We will promote the idea with other communities. Peace! Teemu (talk) 10:47, 10 November 2024 (UTC)[reply]
@Teemu: what on earth made you think my issue here is hurt feelings? I will reiterate and say what I said, less politely and more clearly: Commons is not a suitable venue to gather primary source materials with potentially complex copyright issues. - Jmabel ! talk 18:39, 10 November 2024 (UTC)[reply]
Thank you @Jmabel. I guess I miss interpreted this: “. . . before trying to propose something here”. It sounded very emotionally loaded for me.
What I do not agree with, is your statement:
“Commons is not a suitable venue to gather primary source materials with potentially complex copyright issues.
Commons, as a media file repository for educational media content is exactly a “venue to gather primary source materials” It is also true that related to most of these materials there are “complex copyright issues”.
I am, however, thankful that you expressed your concerns and we will pay attention to them when we progress the project with other communities. 2001:14BA:6EC3:9100:B06C:5520:FBA4:C190 03:31, 11 November 2024 (UTC)[reply]
Reminder to login when editing. All the Best -- Chuck Talk 04:33, 11 November 2024 (UTC)[reply]

Advanced rights and moderation task demand announcements

[edit]

In all discussions about requests for rights for Bureaucrats, Oversighters and Checkusers there is the question if there is a demand for more people with these rights. Therefore I propose to set up a page where the users who currently have this right announce their demand for help going form "we are to many for the work" to "more people critical needed". They should update the demand at least every six month (if there is no change confirming that there is no change). This page could also include the demand on the different admin and some non admin rights requiring maintenance task like: Deletion requests, speedy deletion request, user disputes, vandalism and page protection, patrolling, image reviewing, answering new users questions. This would help for users who are willing to help with maintenance tasks to see where there is a demand for help. GPSLeo (talk) 06:53, 8 November 2024 (UTC)[reply]

 Support Why not? Although it does seem like we could use another Oversighter and another Checkuser since there are only 3. Abzeronow (talk) 20:53, 10 November 2024 (UTC)[reply]
 Support per Abzeronow. Can we make it a template/userbox similar to wp:Pending Changes backlog-defcon? All the Best -- Chuck Talk 01:32, 11 November 2024 (UTC)[reply]
 Support This looks reasonable. --Yann (talk) 19:05, 12 November 2024 (UTC)[reply]
Why a new page? just shoot the msg at vp. and Category:Commons backlog and Category:Commons admin backlog are here. RoyZuo (talk) 18:18, 14 November 2024 (UTC)[reply]

Prioritize support for the upload of DNG (RAW) image files

[edit]

So, this proposal is not new by a long shot. Such proposal was roughly approved in 2009 with a ticket created shortly after and it remains open. There are no significant technical hurdles to implementing this, since DNGs usually include embedded RGB thumbnails that would allow for easy visualization in browsers.

DNGs should be used in Commons and I'm not going to go into too much technical details on why, except to say: RAW images are by far the most efficient and compact way to preserve as much detail as possible of a photograph. Nearly all digital cameras capture just one color (red, green or blue, alternately) for each pixel, usually in 12 or 14 bits, and then creates an RGB image by combining that pixel's information with that of its neighbors in a process called demosaicing. Most images (JPGs, for instance) and most color monitors store and display only as much as 8 bits per channel (R, G or B), generating 24 bits-per-pixel images. Those images are then often compressed in a "lossy" way, that is, information that doesn't impact how an image looks to the human eye gets thrown away for the sake of file size economy - and that's why 24 bits-per-pixel JPGs are usually smaller than 12 or 14 bits-per-pixel that you find in RAW files. Those two steps (demosaicing and compressing) involve several different creative choices and each of these choices almost always "throws away" part of the information that was initially captured by the camera. One can always create 16-bit TIFF files, which are accepted in Commons, but they still carry choices from the demosaicing process and are, usually, much larger than RAW files (since they store 16 bits of information per channel, 48 in total, for each pixel that originally contained 14 bits of information). So 16-bit TIFFs are usually larger AND carry less information than RAW files. So there's absolutely no practical reason why we shouldn't be accepting RAW files in Commons. DNG is the most used format for RAW files.

As far as I can see, the one thing that's held back the implementation of DNG uploads here is a misconception about DNG's legal status. This Community Wishlist thread from 2016 rejected its adoption based on two incorrect premises: that it is a proprietary format and that there are free alternatives. Those premises are incorrect because:

  • while the format was developed and patented by Adobe, that very patent grants "all individuals and organizations the worldwide, royalty-free, nontransferable, nonexclusive right under all Essential Claims to make, have made, use, sell, import, and distribute Compliant Implementations". So while it isn't (wasn't, see below) formally in the Public Domain or licensed under CC, it's free. Some people have claimed that these rights are "revokable", the very patent determines that the one situation where it can be revoked is "in the event that such licensee or its affiliates brings any patent action against Adobe or its affiliates related to the reading or writing of files that comply with the DNG Specification". So, in practice, it's not actually revokable (unless WMF decides to sue Adobe for whatever reason specifically related to the reading or writing of DNG files).
  • there are actually no free, widespread alternatives to storing RAW image files. OpenRAW, while having a significant impact in the field, never actually documented an open raw format. OpenEXR isn't the same thing.
  • DNG is the only RAW format recommended to be used by institutions such as the Library of Congress (see the "sustainability factors" section).
  • although I haven't found confirmation of this (which makes sense since the patent's status is virtually irrelevant for the facts stated above), the Adobe patent was first filed in September 2004, which means over 20 years have since passed and the patents is now in the public domain.

For all I exposed above, we're throwing away relevant information from image files that could be invaluable in the future or uploading huge 48 bits-per-pixel files that can easily go into the hundreds of megabytes per file; or, most often, both. Therefore, I believe adopting DNG as an accepted file format here in the Commons is important and should be made a priority.

Rkieferbaum (talk) 20:57, 11 November 2024 (UTC)[reply]

 Support Sounds good --PantheraLeo1359531 😺 (talk) 15:14, 12 November 2024 (UTC)[reply]
If the legal problems are solved it is only a technical problem to add proper support in MediaWiki. The most important thing for RAW files is that we need a content model that links processed versions to the RAW file. This problem need a solution first. We should not start doing this with Wikitext "see also" oder "other versions" templates. GPSLeo (talk) 15:38, 12 November 2024 (UTC)[reply]
@GPSLeo: Why should we not use "other versions" for this? It seems to me to be exactly what it is for. - Jmabel ! talk 18:30, 12 November 2024 (UTC)[reply]
@GPSLeo: there isn't and actually never was any sort of claim regarding the legality of the matter. Some people dislike the fact that DNG is patented and the right to use it is “revokable”, but, as I explained, those are non-issues. As for processed versions, once again that's a non-issue IMHO, since DNGs inherently carry image settings that allow any software to extract a “standard” JPG from it without the need for always having a separate JPG uploaded in parallel. Those instructions are enough to generate all the previews of an image while the DNG remains available for download. I do believe it would be interesting to have a process for creating “virtual copies” of a DNG - that is, basic instructions for different crops and color treatments of an image without the need of creating and uploading a derivative file. But that's just speculation on my part and in no way a restriction to the adoption of DNG uploads. Rkieferbaum (talk) 18:32, 12 November 2024 (UTC)[reply]
The problem with having the link in Wikitext is that it is not machine readable. I want an API where I can request the RAW file for my JPG or a specific processed version for a RAW file. The embedded thumbnail in the RAW file is to small even for the use in Wikipedia articles. I think the WMF legal team saw some problems and if they have problems with a feature it is also a problem for us. The first step needs to be to get their okay. GPSLeo (talk) 19:10, 12 November 2024 (UTC)[reply]
@GPSLeo: there’s the embedded, low-res preview, but there’s also information (WB, tone, etc.) that allows for any of a handful of free software to generate a full-resolution RGB. That’s what I was referring to. As to legal challenges raised by WMF, I searched the topic as well as I could before posting this, and I never found anything related to legal issues. Would you mind pointing to anything related to that matter? Rkieferbaum (talk) 22:27, 12 November 2024 (UTC)[reply]
@GPSLeo:
  1. "not in the API" is not the same as "not-machine readable"
  2. I would presume humans are still our primary users. I have no objection to this being in the SDC, but I think it is ridiculous to say it should not also be in the wikitext. SDC is roughly as inconvenient for most humans as text is for bots.
Jmabel ! talk 21:11, 14 November 2024 (UTC)[reply]
You would find it "interesting" is at least something. What would be a reasonable assumption for the change in filesize between jpg to DNG? Maybe 10 times larger? Alexpl (talk) 07:43, 19 November 2024 (UTC)[reply]
@Alexpl: of course it depends on a number of factors, but in any case it's unlikely you'll reach that much of a difference when comparing to high-quality JPGs. You're probably looking at around 3 to 4 times on average. Rkieferbaum (talk) 20:41, 19 November 2024 (UTC)[reply]

username verification at Commons

[edit]

Commons:Username policy since Special:Diff/355439634 says: "Use of the names of organizations is allowed on Commons only if you verify your account, proving that you are or represent the respective organization."

It has never been Common sense since then that account verification is mandatory at Commons. There are currently only 542 transclusions of Template:Verified account.

Compared to Wikipedias, either company accounts are discouraged completely, or account verification is done to lay open concflicts of interest, or to grant company accounts some leeway when uptating employee numbers or similar without proof, or any similar. Nothing of all that applies to Commons, account verification doesn't make any sense here, not least as it cannot replace file permissions. Additionally the Volunteer Response Team doesn't have procedures for account verification at Commons, nor any capacity to handle them at large scale.

To adjust the username policy to common practice and common sense, I suggest to replace: 

Use of the names of organizations is allowed on Commons only if you verify your account, proving that you are or represent the respective organization.

to: 

Use of the names of organizations is allowed on Commons. Account verification, proving that you are or represent the respective organization, shall happen only in controversial cases.

Please comment. Thank you. --Krd 03:25, 19 November 2024 (UTC)[reply]

See also: Commons:Village pump/Proposals/Archive/2019/06#Update the username policy.

--Achim55 (talk) 08:06, 19 November 2024 (UTC)[reply]

This is asking for someone to take advantage of it. All the Best -- Chuck Talk 16:34, 19 November 2024 (UTC)[reply]
I would not change the username policy. But I think it would be good to optimize the VRT process. Verification on an other Wiki should be recognized on Commons and account verification and copyright permissions should always come together. GPSLeo (talk) 16:46, 19 November 2024 (UTC)[reply]
I think that we should make the policy that files donated by companies should have to go through VRT from a corporate email. All the Best -- Chuck Talk 17:04, 19 November 2024 (UTC)[reply]
This is already how permission for such files is handled. The only problem is that files are often not recognized as requiring license confirmation. But this is a problem where there are currently experiments how the UploadWizard process could help in such cases. GPSLeo (talk) 17:50, 19 November 2024 (UTC)[reply]
Yes, I also thought that this was policy, as literally anyone can make an account named "Microsoft-official" or "Google-official" and claim to representatives of the corporation. As far as I know, every file donated from corporations require VRTS permission. I specifically created "Template:Welcomeorganisation" many years ago to help people working for organisations to understand how things work around here; and everything in that template is based on official policies and guidelines. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:27, 27 November 2024 (UTC)[reply]
@GPSLeo: This is not a good idea because being verified to speak for a company, and the company really being copyright holder of the uploads, are two different things. Bypassing the permission process for verified accounts will create issues. Krd 12:20, 28 November 2024 (UTC)[reply]
My suggestion was not to skip the process but to put them together. Account verification without copyright verification should only be possible if no content uploads are planned. GPSLeo (talk) 13:44, 28 November 2024 (UTC)[reply]
A verified account can be the copyright holder of one file but perhaps isn‘t of the next. If each file of such account goes though the permission process, what exactly is the account verification good for? Krd 14:08, 28 November 2024 (UTC)[reply]
I would say the verification is valid for all works of one author or one attribution if the original authors give all rights to the organization. GPSLeo (talk) 15:06, 28 November 2024 (UTC)[reply]
"A verified account can be the copyright holder of one file but perhaps isn‘t of the next." How is this different from every normal Commons account? We normally assume good faith about claims of "own work" until we have specific reason to believe otherwise. Why should this be different for people authorized to upload on behalf of an organization? Why should an email to VRT carry any more weight than a post by an authorized, verified representative who operates an account? - Jmabel ! talk 18:37, 28 November 2024 (UTC)[reply]

Category Name Change Re:Trump 2nd Term

[edit]

Should we change Category:Photographs from the White House during the Trump administration to say "during the First Trump administration"? With it we might also change other categories too like Category:Cabinet members of the Donald Trump administration to First as well. This would then bleed over into Category:Cabinet members of the Grover Cleveland administration as well. Thoughts? SDudley (talk) 19:04, 19 November 2024 (UTC)[reply]

Makes sense, maybe add a parent cat "Cabinet members of the Donald Trump administrations", and the same for Grover Cleveland. All the Best -- Chuck Talk 23:43, 19 November 2024 (UTC)[reply]
+1 --PantheraLeo1359531 😺 (talk) 18:41, 24 November 2024 (UTC)[reply]

Move most diagram categories to infographic categories

[edit]

This has been talked to death. See here:

Bottom line is that I and a couple admins agree. Along with a native German speaker who confirmed that some people are trying to use the broad German definition of "diagram" to mean an overall English term like "infographic". Categories:

There is a Wikipedia page now for infographic: infographic.

Generally speaking infographic is the broad term for all graphics other than photographs. --Timeshifter (talk) 09:24, 24 November 2024 (UTC)[reply]

"Generally speaking infographic is the broad term for all graphics other than photographs". No, it is not. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:13, 24 November 2024 (UTC)[reply]
There are indeed many other types of images that are neither infographics nor photos such as illustrations. I think something needs to be done but I'm not sure what – I think it includes moving many files or categories, like Charts subcategory, into the datagraphics category which is more explicit or specific and better-understood or better-delineated with what's meant. Somebody need to clear up the confusion around the distinctions between charts, graphs, diagrams, etc. For example Charts says The term "chart" as a graphical representation of data has multiple meanings:
[1.] A data chart is a type of diagram or graph, that organizes and represents a set of numerical or qualitative data. [2. ...] while other websites distinguish charts as something separate from diagrams. The current situation makes things more difficult to find and is somewhat unclear. Prototyperspective (talk) 17:52, 24 November 2024 (UTC)[reply]
The infobox at the top of Category:Diagrams has the common English meaning: "plan, drawing, sketch or outline to show how something works or the relationships between the parts of a whole"
Non-photo illustrations are infographics. Any kind of info-based graphic is an infographic. Info includes data. A diagram without data is still sharing info. So it is an infographic. A diagram with data is also a datagraphic.
Datagraphics does not include infographics that are not data-based.
Charts includes graphs, but not diagrams. According to the common usage.
Data-based charts are a subcategory of datagraphics. Datagraphics includes a broad range of data-based graphics including data-based maps such as choropleths.
If we go by the common meanings of the terms, categorization is much simpler.
--Timeshifter (talk) 01:27, 25 November 2024 (UTC)[reply]
Yes. I guess it should be clearer which subcategories you're referring to. I named one that I think needs to be moved.
No, non-photo illustrations aren't infographics except if they're diagrams which can be considered infographics. So for example if it just illustrates how some animal looks like (rather than e.g. labels for different highlighted anatomical parts thereof) then it's not an infographic just like a photo of the animal that likewise shows how an animal looks like is not an infographic.
--Prototyperspective (talk) 11:06, 25 November 2024 (UTC)[reply]

I see what you mean. A line drawing of an animal without labels is not an infographic. I assumed incorrectly that you meant a labeled illustration.

I wonder if editorial cartoons, cartoon strips, or the labeled illustrations in graphic novels are infographics. Many cartoon strips are stories. Some cartoons can be educational. So the info can be a story, educational info, humor, protest, etc.. Are any of those considered infographics. I don't know.

I agree with you about datagraphics. I think much of the stuff in the diagram categories are datagraphics. Charts, graphs, etc.. A few files are diagrams. As you said, diagrams are infographics. A non-data-based diagram is not a datagraphic. An exploded illustrative diagram of parts, for example, often has no data.

So since all diagrams are infographics I think most of the categories in Category:Diagrams can be moved to Category:Information graphics. Basically, just substitute "infographics" for "diagrams" in the category names. So we would be substituting a more accurate category name for a less accurate category name.

Some of the diagram categories may actually contain nothing but genuine diagrams (from the common definition). In that case they can keep "diagram" in the category name. But most diagram categories I have checked have charts, graphs, maps, and other non-diagram files mixed in. --Timeshifter (talk) 09:11, 26 November 2024 (UTC)[reply]

Standardizing categories for films

[edit]

Hi, I propose that we standardize categories for films. Currently there are sorts of formats. I think that categories for films should have the format Film name (year). That should be quite easy, at least for films in English. For other languages, we usually use the translated name in English. There may be an issue when there is not a single English translation. This may require a lot of categories renaming, so it is better to have an agreement before doing anything. Yann (talk) 16:48, 25 November 2024 (UTC)[reply]

There is no reason to preemptively disambiguate titles. Why "Film name (year)" instead of "Film name (country of origin)" or "Film name (language)" or anything else? And why only films? —Justin (koavf)❤T☮C☺M☯ 16:51, 25 November 2024 (UTC)[reply]
"Film name (year)" is the better way to disambiguate because a lot of movies originate from Hollywood and sometimes they'll share the same name, for instance Dressed to Kill, Dressed to Kill, Dressed to Kill and Dressed to Kill, which are all English-language (except for the first, which was a silent film), American productions. I imagine Indian and Chinese cinema would run into the same issue if they're disambugated by language/country of origin rather than year of release, though I'm not as familiar with their output.
And films kind of stand apart from other media productions because films that reach the kind of notability that allows them to be on Wikipedia (and Commons by extension) are usually large productions, so it's unlikely you'll get two movies with the same title in the same year (although this has happened before, see Chaos (2005 action film) and Chaos (2005 horror film)). Video games are in a similar space, although on a fairly regular basis I see indie games reach a level of notability and success I almost never see for indie cinema. ReneeWrites (talk) 18:07, 25 November 2024 (UTC)[reply]
@Koavf: The idea is not primarily to disambiguate titles, but to have predictable names. The year is always the first way to designate a film name. Yann (talk) 18:59, 25 November 2024 (UTC)[reply]
I'm good with disambiguation when necessary, but these names will be far less predictable. I could guess Category:Citizen Kane but would this be Category:Citizen Kane (1939) or Category:Citizen Kane (1941) or whatever? I can't recall the release date of that film, but I can recall its name. —Justin (koavf)❤T☮C☺M☯ 19:11, 25 November 2024 (UTC)[reply]
If this is done, there needs to always be a disambiguation category without the year (or a cat redirect if there is only one such film). - Jmabel ! talk 19:30, 25 November 2024 (UTC)[reply]
I see your point, but currently, we have the following categories: Name, Name (film), Name (year film), and Name (year). So I think it would be good to rename at least the 2nd and 3rd categories. Yann (talk) 19:42, 25 November 2024 (UTC)[reply]
Tend to support this but I think that's already being done when there's multiple films of the same name. There is no need for it when there's only one film with that name so if you're suggesting to also add it for these I'm not sure if that would be good but it could also be useful (e.g. if at a later point there is a film of the same name). In some contexts (ie categories that are not specific to films), having (film) in the title would be helpful – if it's just the year it could as well be a novel for example depending on the context. Prototyperspective (talk) 22:24, 25 November 2024 (UTC)[reply]
It's hard to believe that Category:Gone with the Wind (film) would be easier to find by needing to know what year it was released. - Jmabel ! talk 00:17, 26 November 2024 (UTC)[reply]
Yeah, I imagine Category:The Wizard of Oz (1939) is not what most people would use to find the one that they remember. (and of course some wouldn't immediately try Gone with the Wind (1939) ). Abzeronow (talk) 17:52, 26 November 2024 (UTC)[reply]
Makes no sense. People don't find categories by typing out the category into the url bar. Prototyperspective (talk) 18:03, 26 November 2024 (UTC)[reply]
I do just that with great frequency. - Jmabel ! talk 22:59, 26 November 2024 (UTC)[reply]
With finding I was referring to finding categories one hasn't visited before where it would not show an autocomplete for the category. It makes sense to type a simple category name like category:LibreOffice or category:Blankets there as a Commons contributor. I don't think that's how users usually find categories especially when you have to capitalize words right as with film names, you need to know exactly where the page is you're looking for. In general one can enter it into the search bar which should suggest an autocomplete for the category…I just noticed however that it doesn't suggest Wizard of Oz categories when entering "The Wizard of Oz" there. It may be best to have a redirect so that for every film there is one page or redirect with the year and one without (being a disambig page if there's multiple categories for the film). (Don't think that would be important or currently much needed however.) Prototyperspective (talk) 23:37, 26 November 2024 (UTC)[reply]
"Filmname (yyyy)" is a pretty common notation seen in many film websites. do some users not use film websites at all? RoyZuo (talk) 11:22, 29 November 2024 (UTC)[reply]
and ofc, if nothing else has the same name, commons cat title doesnt need the yyyy suffix. RoyZuo (talk) 11:23, 29 November 2024 (UTC)[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=964535797"