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]

Deleting empty categories

[edit]

I recently asked whether there is a page about empty categories and since apparently there is no I created Commons:Empty categories. Please comment or edit if there's anything to add.

I'd like to propose that all empty categories older than several months (3, 6, or 12) are deleted. This would need some bot or script doing this large-scale as there are many thousands of them. Could this please be done?

Excluded would be:

  • Redirects
  • Disambiguation pages
  • Maintenance pages
  • Pages soon to be populated such as cats that are part of a natural series with a cat for every year or for campaigns set up before the campaign because the category would still be empty after 3-12 months

All of these pages could be excluded in the query. Moreover, even if a small number of empty categories are being deleted in accordance with SC2 despite being not unlikely to be populated soon then it's simple to just recreate them while these empty categories are a problem and the benefits of deleting them clearly outweigh that a handful of recreatable categories have been deleted which could have been tagged for speedy deletion anyway.

A main issue with empty categories is that they don't have a NOINDEX magic word and so could be indexed – and maybe frequently would be if WMC cat pages were indexed better in general like they should be. This is one of the main problems with empty categories. Other issues include that they make pages harder to oversee / clutter pages and that when linked to Wikidata items give the impression that there's media here about the subject but lead to just an empty page. They can also cause category cycles. I don't see any good reason to keep them which is probably also why it's a speedy deletion criteria.

Proposed steps:

  1. Identify any potential complications with implementing this other than the ones already in "Special types of empty categories" in the page linked (maybe some maintenance categories do not have {{Maintenance category}} and/or {{EmptyCatGood}} set which should soon put them into Category:Maintenance categories) and fixing these issues
  2. Adjust the Quarry query for empty categories below so it returns all empty categories that should be deleted
  3. Use the query output to then delete them in some way, maybe with a bot adding the speedy delete notes a week before deletion and then deleting all the still empty ones or deleting them directly with some mass-delete tool/script

How could each of these steps be done? Especially the third one seems to need some work (technical development).

Here's the Quarry query for all empty categories (without redirects and disambigs): Quarry:query/7200. It shows there are really many empty categories.
Prototyperspective (talk) 16:11, 26 October 2024 (UTC)[reply]

I would say that every category that has a Wikidata item linked should not be deleted if empty. This does only not apply when it is not simple to make photos to populate the category. This is the case for:
  • Past events
  • Events further in the future than 1 year
  • Dead people
  • Artworks still in copyright
  • Not photographable with regular equipment (e.g. most asteroids, planets)
All empty categories they are not linked to Wikidata for more than one week should be deleted. We have a huge problem with new users failing to add proper categories. Having empty categories linked to Wikidata could make this much more easy for new users. A category linked form Wikidata should not give we impression that there might be files about the item when the item has no photo linked. If there are photos in the category but no photo on the item that is a different problem that is easy to solve with tools already existing. GPSLeo (talk) 16:45, 26 October 2024 (UTC)[reply]
Aren't empty categories linked to Wikidata items even more problematic: they give users the impression that there's media on Commons when that isn't the case. If they come here and don't know the site well they'd be confused and see an empty page wondering why that Wikipedia linked to it. I think empty categories linked to Wikidata items are more problematic than empty categories not linked to from anywhere other than their parent categories. Btw, there are many cases where there's files in the WMC categories but none of them is suitable for being linked in the Image property of the Wikidata item which should contain only somewhat representative/useful files. Whether it should is not relevant to whether or not it does. Prototyperspective (talk) 16:51, 26 October 2024 (UTC)[reply]
Not really, there are lists at Wikipedia that help users upload photos directly to the correct category.
 ∞∞ Enhancing999 (talk) 16:54, 26 October 2024 (UTC)[reply]
These cases are excluded by all empty categories older than several months (3, 6, or 12) are deleted. Moreover, these tools (link?) could also set a redcategory and/or create the category automatically/request its creation after there is a file. I don't think empty categories are used for that anyway. Prototyperspective (talk) 16:56, 26 October 2024 (UTC)[reply]
I don't see how the creation date has anything to do with that. Not sure how doing maintenance on red categories instead is an advantage.
 ∞∞ Enhancing999 (talk) 17:16, 26 October 2024 (UTC)[reply]
If you argue (still without any substantiation) that these help users upload photos directly to the correct category then there would be files in them after 3, 6, or 12 months. Well then create the category at upload but I don't think this is an actual scenario, not even a niche rare one. Prototyperspective (talk) 17:36, 26 October 2024 (UTC)[reply]
But then we need a way to store the intended category name and the parent categories for this category on Wikidata. And we need an automated process that creates it and links it when added in the UploadWizard. GPSLeo (talk) 17:51, 26 October 2024 (UTC)[reply]
It seems to be already stored if an existing category is selected so it wouldn't really make a difference. In any case this varies or depends on the actual thing discussed so a link would be needed. I still think nothing of this sort actually exists. Prototyperspective (talk) 20:39, 26 October 2024 (UTC)[reply]
I think the main problem are malformed empty categories (we deleted hundreds of them). Once categories are linked to Wikidata, this is considerably less problematic. I think the current speedy deletion policy captures the situation fairly well.
 ∞∞ Enhancing999 (talk) 16:51, 26 October 2024 (UTC)[reply]
Why would it be less problematic? See my comment above: it leads users to a useless empty page by being linked from Wikipedia and possibly search engines. There is no use in having a Commons category that is empty linked to a Wikidata item. Prototyperspective (talk) 16:52, 26 October 2024 (UTC)[reply]
You could easily navigate to parent categories and find files there.
 ∞∞ Enhancing999 (talk) 17:17, 26 October 2024 (UTC)[reply]
Often times the files are for things that the person isn't looking for to begin with though. So how exactly is that helpful? --Adamant1 (talk) 17:36, 26 October 2024 (UTC)[reply]
Good point. Users on mobile still do not even see these however. Also I think for these cases something other could and should be done. For example, in Wikipedia pages there may be several images and one can open them and then navigate to their categories. Prototyperspective (talk) 17:37, 26 October 2024 (UTC)[reply]
We know we need to fix categories for mobile users, but that isn't really a reason to delete all categories before.
 ∞∞ Enhancing999 (talk) 17:39, 26 October 2024 (UTC)[reply]
In such cases it would be better to link to the parent category on WMC directly in the Commons category template. Prototyperspective (talk) 20:37, 26 October 2024 (UTC)[reply]
  •  Support I don't really get the argument for keeping empty categories just because there's a Wikidata item associated with them either. For one it makes it seem like we have media for subjects that we don't and secondly it puts the onus for it's do things in Commons or not on Wikidata users. Which wouldn't be that much of an issue, but there's absolutely zero standards what-so-ever on Wikidata's for what deserves to have an item or not. So essentially anything could have a category on Commons regardless if there is or ever will be media related to it on our end simply a random user of Wikidata decided to create an item for it. No one on here is served by hundreds of thousands of empty categories that will never be used to organize media and/or can't be deleted. If anything there should be more rules on when and under what circumstances it's OK to create categories, not less. --Adamant1 (talk) 17:36, 26 October 2024 (UTC)[reply]
    But where do you propose to store the information about the relevant parent categories if the category itself should not exist until it is used? GPSLeo (talk) 17:59, 26 October 2024 (UTC)[reply]
    Parent categories are not hard to find and it's not important to store parent cat info of cats that are empty anyway and would be deleted on sight by a user who thinks of speedy-delete-tagging it. There can be innovation around media requests (as in please create a category about x; suggested parent cats: yz) and this would be enabled or boosted by deleting empty cats. Prototyperspective (talk) 20:36, 26 October 2024 (UTC)[reply]
    I am admin on Commons and for me it is often complicated to find the correct parent category. In most cases I use Wikidata to enter the category tree near the place I am looking for. From my patrolling work and when talking to new users I know that they do not know how to handle the category system. If we have a Wikidata item about something we should use this data. This could of course all be done by some fancy software. But we do not have this at the moment and the WMF will definitely not help us getting such a tool. Or we just use empty categories to solve this problem. The long term goal is to replace categories by structured data anyway. GPSLeo (talk) 20:47, 26 October 2024 (UTC)[reply]
    If we have a Wikidata item about something we should use this data Sure, agree. After creating a category, contributors can check the wikidata item if it has relevant data. This could of course all be done by some fancy software. It's already done by the Wikidata Infobox and I supported a current proposal to make it auto-add more categories and there could be more cats that it auto-adds. we just use empty categories to solve this problem Empty categories don't solve any problem whatsoever. Their categories are often flawed anyway and they may never be populated ever or are empty because they are flawed to begin with and shouldn't be populated. Structured data is not used and not nearly as useful as categories. Where structured data exists, it's usually because categories were copied to structured data or because the uploader entered the same data twice once for categories and once for SD. Less often but still very often they contain flawed or overly broad data such as depicts "building" or depicts "human". And in nearly all cases it contains not even 3/4 of the metadata specified in categories. Prototyperspective (talk) 21:15, 26 October 2024 (UTC)[reply]
  • @GPSLeo: Maybe I'm just being dumb here but I can't image an instance where that would be a problem. Like if someone is looking for a category related to brown cars and it doesn't exist the obvious thing is to look for a category based on cars by color or just cars. Although I will caveat that by saying there some instances where categories take abrupt right turns sometimes but that's an issue with how people create categories more generally and doesn't really have anything to do with this IMO. So can you give an example of what your talking about? --Adamant1 (talk) 00:22, 27 October 2024 (UTC)[reply]
 Question what problem are you trying to solve? Category cycles aren't possible with empty categories.
 ∞∞ Enhancing999 (talk) 17:56, 26 October 2024 (UTC)[reply]
The main thing was that these pages are not no-indexed and the spiders may not distinguish between categories that are empty and those that aren't which could cause issues for the presence of WMC in search results overall. There are further things like empty categories filling backlog reports and HotCat autocompletes. Some of them may also fill category pages making things hard to see and such cases would be solved by this even when there's usually only a small number of empty cats in a cat if any.
I'd say it's not important to me at all and it may not be worth doing or not now despite that there's no good reason not to...but then please make empty categories noindexed. It's not a priority issue but reducing the noise and reducing the really large number of categories by a significant number seems like a good thing to do.
Good point about the category cycles, e.g. categories containing just an otherwise empty subcategory containing itself wouldn't be considered empty. Prototyperspective (talk) 20:30, 26 October 2024 (UTC)[reply]
You want to hide the missing content. But the information what is missing is the most important as we want to fill these gaps. GPSLeo (talk) 20:53, 26 October 2024 (UTC)[reply]
Exactly. And this is why we need a proper media request system. No, I don't want to hide that and empty categories are not the right way for that (including being entirely ineffective in regards to that). Prototyperspective (talk) 21:05, 26 October 2024 (UTC)[reply]
 Question how do you intend to make the thing about 3-12 months work? Consider the following scenario: Category:Night markets in Singapore was created in2009 and has 17 photos. Let's say a vandal removes the category from all of those photos. How does the bot know this is a recently emptied category rather than a 15-year-old category that has never been used? - Jmabel ! talk 18:40, 26 October 2024 (UTC)[reply]
Good point. It's because vandals don't know that and when such a trimming would occur and the very few cases where something like this happens the category can simply be recreated (in this case: 1. revert that user's diffs 2. notice the redcat 3. recreate it using the similar Category:Night markets in Cambodia). Prototyperspective (talk) 20:33, 26 October 2024 (UTC)[reply]
On rare occasions I created a category that I intended to fill but forgot to use when later uploading the photos. Sometimes empty categories are duplicates to other categories, then they should be turned into a redirect. I have never experienced a problem with an empty category whatsoever. On the other hand you can give pictures a category that does not exist and when you click the link you still see all the pictures in that category. I wonder how many of these exist and they are hard to detect, because you can not find them with the search tools or in the category tree. I consider that a problem--Giftzwerg 88 (talk) 20:44, 26 October 2024 (UTC)[reply]
Deleting empty categories would help there in making people add the actual category instead of the empty duplicate one. Empty categories are not a big problem. Many thousands of them exist. Nonexistent categories is a different separate subject. One can also create a query to see these but those containing more than x (14 I think it was last time I checked) number of files are in Special:WantedCategories. Prototyperspective (talk) 20:51, 26 October 2024 (UTC)[reply]
The duplicate category problem is solved by the requirement of linking them to Wikidata. Then there are only duplicates if there is a duplicate on Wikidata. GPSLeo (talk) 20:55, 26 October 2024 (UTC)[reply]
An estimated 90% of categories are not linked to wikidata. If the remainder, that is tens of thousands of categories, were linked to a Wikidata item, then the problem would simply exist on both sites rather than just on one which is not an improvement. Secondly this is unrelated or at most tangential to the subject/thread. Prototyperspective (talk) 21:08, 26 October 2024 (UTC)[reply]
What is the current policy about Wikdata items? Is it desirable to have an item for each commonscat? I am a fan of infobox wikidata and use them often but not for all categories. For example I would not use it for something like Category:Rivers of Landkreis Böblingen or Category:Automobiles at Motorworld Region Stuttgart but definitely would use it for each individual river or water body. A lot of these categories are just to divide the material by administrative boundaries or by years or other artificial criteria.--Giftzwerg 88 (talk) 00:06, 27 October 2024 (UTC)[reply]
Totally personal preferences here, but IMO there should be a Wikidata item for "main subjects" (however you want to define that). It would be super pointless and obtuse to have a Wikidata item for every single minor category and/or subject on here though. Especially when if your talking about intersectional categories involving multiple characteristics. Generally though, I'd say the more obscure and less likely to be stable a category is then there's less point in having a Wikidata item for it. There's zero point in having Wikidata items for categories that have a large chance of just being deleted. --Adamant1 (talk) 00:35, 27 October 2024 (UTC)[reply]
  • @GPSLeo: I run into instances all the time where a category is empty due to the media that was previously deleted as either COPYVIO or OOS. Plenty of them had Wikidata infobox to. Regardless, what would be your solution in an instance like that? In both cases there's essentially zero chance of there ever being media to put in the categories. So should we just keep inherently empty categories for subjects that are clearly COPYIO and/or out of scope simply because they are notable enough for a Wikidata item? --Adamant1 (talk) 00:29, 27 October 2024 (UTC)[reply]
    The first case was already in my list of exceptions where a category should be deleted. In the second case the Wikidata item is out of scope and therefore there will be no Infobox after the item is deleted. And I also would nominate the item for deletion and delete the category with its content in parallel. GPSLeo (talk) 05:41, 27 October 2024 (UTC)[reply]
Hm. Useful empty categories were removed as a speedy deletion reason a while ago; discussion at Commons talk:Criteria for speedy deletion/Archive_2#Speedy_deletion_of_**empty**_categories. There can be categories with substantial content in them (categorized in other places, or some researched text) that seems callous to just delete, if there is a reasonable chance that the categories will be re-populated again (maybe once the files once inside have their copyright expire, or other ones found -- undeletions happen too). There are likely many ship categories in that state, and I'm sure many other examples. I'm sure there are many examples of empty categories which should be deleted, but also many examples of ones which should be kept, and not sure automated deletion is a good idea. Maybe if there is minimal content in empty categories -- but then again, that older discussion lists several reasons to keep certain empty categories and not sure there is a way to really automate those distinctions. For duplicate categories, definitely prefer redirects to deletion, unless there was an outright mistake in the category name. For the most part, I have not seen big issues with empty categories. They are mildly annoying but deleting other people's work for the sake of a little cleanliness does not seem like the right approach. The argument that they are easy to recreate falls flat to me -- some of them have quite a bit of categorization or text on them. A report showing old, empty categories for more careful human review may make some sense. If the wiki software could be made to no-index them when there are no files and no visible text, I could see that. Carl Lindberg (talk) 01:20, 27 October 2024 (UTC)[reply]

Create a noratelimit user group

[edit]

This group would have the noratelimit user right per COM:BN#Rollback rate limit increase for Alachuckthebuck.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:00, 30 October 2024 (UTC)[reply]

I have some concerns:
  1. who will be granted this right and when?
  2. who will be able to grant this right?
  3. if this is for a one-time case or a rare-issue, don't you think it is odd to have this group created when "bot" can be utilised?
As such I don't think this would be a good-to-go idea. Regards, Aafi (talk) 14:14, 30 October 2024 (UTC)[reply]
@Aafi: The group membership would be granted to applicants by Bureaucrats, or possibly by Admins if the community deems that advisable.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:26, 30 October 2024 (UTC)[reply]
and "when" - I mean what are the factors that would determine the need of such a user right? To override rate-limit means only to do things at a bulk rate which is otherwise impossible for a human editor. There is a visible collision between a bot's job & the noratelimit edit's being done by a human! Regards, Aafi (talk) 15:35, 30 October 2024 (UTC)[reply]
What are the cases for having no rate limit they do not require bot approval? In the given case I also think that massively correcting bad bot edits should also be marked as a bot edit. GPSLeo (talk) 14:14, 30 October 2024 (UTC)[reply]
+1 Krd 14:20, 30 October 2024 (UTC)[reply]
@Krd: Does your "+1" apply to my proposal or to GPSLeo's reply?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:28, 30 October 2024 (UTC)[reply]
@GPSLeo: Would the bot need approval for the use case presented by Chuck? If so, he should file a bot request. If not, I can use my bot for this use case.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:23, 30 October 2024 (UTC)[reply]
Yes as doing many thousand automated edits is the definition of a bot. If it is about fixing around 3000 files waiting for 30 minutes would also be fine. GPSLeo (talk) 14:29, 30 October 2024 (UTC)[reply]
I would argue that the best way to handle this would be having something similar to the Flooder right, but for non-admins.
The userright (Flooder) has only one permission: the addition and removal of the (Flooder Flag) userright. The permissions of the Flag are edits marked as bot, and the removal of rate limits. The flag is removed automatically after 24 hrs. Usage of the right is only allowed after a bot request (or similar) with approval for the exact task the flag is used for. Running a bot along the lines of what took me 5 hrs (without ratelimits) would be impractical, and also take even longer than cleanup already took. All the Best -- Chuck Talk 15:54, 30 October 2024 (UTC)[reply]
Flooder seems doable. Regards, Aafi (talk) 16:16, 30 October 2024 (UTC)[reply]
If we have a bot request, we can assign the bot flag. This discussion is about a non-problem. Krd 16:18, 30 October 2024 (UTC)[reply]
@Krd, doing 35k rollbacks took me about 5 hrs. programming a bot, getting approval, debugging, then doing the run, and likely handling cleanup, is a 3-5 week project, assuming no problems with programing or regex. And once the run starts, it would still take 5 days at 6 epm. Or we create the Flooder right and do it in 5 hours. All the Best -- Chuck Talk 16:24, 30 October 2024 (UTC)[reply]
Which we did, didn‘t we? So what exactly is needed in addition? Krd 16:42, 30 October 2024 (UTC)[reply]
You wanted mass fixes like this to be bot edits, so I proposed a way to have the benefits of it being done by a user (being done in 5 hrs), and the beniefits of the bot flag (easy filtering, not breaking RTRC). My proposal would allow me to have the flag for the reverts, and remove it when done. Everything's under one account, and done in a fraction of the time a bot would take. All the Best -- Chuck Talk 16:58, 30 October 2024 (UTC)[reply]
I would have liked to avoid bringing up the point, but a question IMHO way more relevant than the details how it actually was rectified, is why a bot operator can do 35k wrong edits and is not able to fix them by his own bot, and if is this is a good situation. Will this happen again? If not, why can't we just stop and go back to business? Krd 17:26, 30 October 2024 (UTC)[reply]
This whole saga is over using the word "the" in the category titles of a Danish GLAM. The were uploaded without "the", then WLKBot added "the" to all categories, and created needed categories, I rolled back to no per the AN thread, and when I finished, a not was posted to my talk, informing me that consensus has changed, and I was requested to undo my edits. I declined, as cat-a-lot will work for this purpose, and if not, AWB can handle it. @Kim Bach, You have some explaining to do. All the Best -- Chuck Talk 21:07, 30 October 2024 (UTC)[reply]
Indeed, a user had opposed the naming convention, "in the" instead of "in" that is commonplace for a number of other GLAMS. I decided, completely wrong, to run a mass edit to fix this problem, when I discovered that this was in error, I requested the rollback, which I think was the right think to do.
I realise that this has wasted a lot of time, this is indeed a fiasco, and 100% my mistake. Kim Bach (talk) 11:22, 1 November 2024 (UTC)[reply]
If we talk about such a group, I think flooder is a doable job. On Wikidata, Flooders have the "bot" permission alongside the ability to remove themselves from the group. Regards, Aafi (talk) 16:24, 30 October 2024 (UTC)[reply]
Automated tools would need to follow mw:API:Etiquette. For example mass editing bots will need to follow if there is load on the server and slow down if there is. For example when en:User:Writ Keeper/Scripts/massRollback was used to revert the 35k edits in yesterday was doing it in unlimited rate, which was 50-100 edits per second, without slowing down when server could not keep up. This is way too high and could cause similar problems than what for example Cat-a-lot did before it was changed. --Zache (talk) 18:56, 30 October 2024 (UTC)[reply]
The script was meant to Mass rollback edits made by vandalism only accounts (50ish edits) and be used once a day. I used it to roll back 35k edits in batches of 1500(give or take 300 edits due to page creations) . I ran a batch every 60-90 seconds. I will modify my local copy of the script to slow down to a more reasonable speed. I also don't see this method of rollback being used at this scale ever again, as a bot to do this kind of cleanup is needed. That doesn't change the need for this right, and the legitmiate points raised by @Krd and @Aafi. All the Best -- Chuck Talk 20:45, 30 October 2024 (UTC)[reply]
Most of usecases are such as it feels to me that it would be used workaround ratelimits in a way that it should not be done. Most clearest examples are tasks would be using Help:VisualFileChange.js to editing large amounts of categories in highspeed. Another note is that admins and bots have noratelimit already and it is actually little bit hard to see what would be the use cases where it would be used (and if the idea is to allow rollbacks to be done in higher speed why not just bump up the rollback limits) --Zache (talk) 05:59, 31 October 2024 (UTC)[reply]
If rollbacks are being done in any quantity near the rollback limit (100 per minute), there should already be consensus for the action. If you need a higher rollback limit, then there should be another request and comment period, that's how we avoid another situation like this. I'm working on a solution to the problem, should be ready to go in the next few days, and is adaptable to do future fixes, and slowly. Sorry for wasting everyone's time with this mess. All the Best -- Chuck Talk 16:33, 31 October 2024 (UTC)[reply]
  •  Oppose Per Zache, Aafi, and others. This mostly just seems like a workaround to rate limits and from what I can tell most or all the people who benefit from it already have other avenues to get around the limit if they really want to anyway. --Adamant1 (talk) 20:04, 31 October 2024 (UTC)[reply]
 Oppose per above arguments Bastique ☎ let's talk! 20:22, 31 October 2024 (UTC)[reply]
 Comment: I bit the bullet, and with some help from @Schlurcher, Have a bot request at com:bot requests#chuckbot. All the Best -- Chuck Talk 06:16, 1 November 2024 (UTC)[reply]
  •  Oppose a separate group, but  Support deprecating account creator in favor of this.
ACC is already a back door version of this – only two ACCs mentioned account creation when asking for/being granted it (emphases mine).
  • Alachuckthebuck – I'm working on cleaning up User:WLKBot's contribs using massrollback, but am running into the (normally gracious) 100 rollbacks per minute limit. Is there a way to remove this limit on my account for the next 3 days or so?
  • Alexis Jazz – I need the account creator (noratelimit) right. I simply can't do my work anymore due to Phabricator: Ratelimit on Commons is way too aggressive/broken.
  • D. Benjamin Miller – Dear bureaucrats: I am a filemover and would like to be given the status of account creator; I find that when working through rename queues I often run into the ratelimit and would like to get around this restriction, please.
  • Effeietsanders (granted by a steward) – for bypassing email rate limits and account creation related to WLM
  • QueerEcoFeminist – I frequently move pages and I have got stumbled upon ratelimit several times. (Sorry I don't know if there is any log to check it!) And I am also involved in real life wiki activities like trainings around wikimedia projects including commons. So account creator right would be great help to me.
  • Sandro Halank – noratelimit per request (don't know where said request was, don't see anything in BN archives)
  • Xaronim – That can be done as well but might need a flag that has a higher rate limit, tried 120 edits and was stuck for a good 15 minutes. (alternative account of Minorax, initially planned to be a bot but became a semi automatic account)
Queen of Hearts (talk) 08:36, 1 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]

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]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=961958298"