Category Name Change Re:Trump 2nd Term

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)

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)

+1 --PantheraLeo1359531 😺 (talk) 18:41, 24 November 2024 (UTC)

Move most diagram categories to infographic categories

This has been talked to death. See here:

• Commons:Categories for discussion/2021/01/Category:Diagrams

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:

• Category:Diagrams
• Category:Information graphics

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)

"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)

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)

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)

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)

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)

Standardizing categories for films

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)

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)

"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)

@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)

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)

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)

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)

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)

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)

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)

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)

I do just that with great frequency. - Jmabel ! talk 22:59, 26 November 2024 (UTC)

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)

"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)

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)

Advanced rights and moderation task demand announcements

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)

 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)

 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)

 Support This looks reasonable. --Yann (talk) 19:05, 12 November 2024 (UTC)

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)

 Neutral I like the idea, but I don't see it happen. The problem arises when users get inactive, and inactive users don't update pages. Also, the highest demand isn't with the three mentioned groups, but with active admins in general. Users who are willing to help are always welcome to comment on deletion request, no special invitation is required. --Krd 07:04, 14 December 2024 (UTC)

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

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)

 Support Sounds good --PantheraLeo1359531 😺 (talk) 15:14, 12 November 2024 (UTC)

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)

@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)

@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)

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)

@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)

@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)

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)

@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)

The DNG file stores much more information (including the unedited version if not postprocessed), but also higher color-depth than JPEG can offer. This is where the larger filesize comes from --PantheraLeo1359531 😺 (talk) 20:22, 12 December 2024 (UTC)

username verification at Commons

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)

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

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

This is asking for someone to take advantage of it. All the Best -- Chuck ^Talk 16:34, 19 November 2024 (UTC)

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)

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)

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)

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)

@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)

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)

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)

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)

"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)

It should not be different, this is why we shouldn't have verified accounts, because they will imply a difference doesn't exist. Krd 06:16, 8 December 2024 (UTC)

@Krd: that makes no sense to me.

When I upload a photo and say I own the copyright, after these many years when I have been here and have a good record, even if I already have posted the image elsewhere (credited to me), presumably no one will ask me to go through VRT to prove my account really is Joe Mabel.

But if we had an account, say, "Bill G. (Gates Foundation)" that was uploading on behalf of the Gates Foundation, are you saying that after they have a certain amount of trakc record we can let them skip VRT for new uploads? I don't think you are, but correct me if I'm wrong.

On the other hand, if we allowed that account to be verified, it seems we could then handle its Gates Foundation uploads pretty much the same way we handle my uploads of my work.

Why is that not desirable? - Jmabel ! talk 18:09, 8 December 2024 (UTC)

The occasion for my proposal is Commons:Volunteer Response Team/Noticeboard#transfer of verification. Do you see any reason to verify this account, which has no uploads, and with the verification assume that their uploads will be own works and have permission? If yes, do you think admins are oblieged to check the user page of the uploader for account verification and consider this for their decision? I think all file licensing information has to be on the file page, and account verification does not make any sense. Krd 06:34, 14 December 2024 (UTC)

Seems useful to me to have verification for that. If they are then challenged on any future uploads for content for that organization, they have something to link in response that should quickly resolve the matter. If that never comes up, no harm done. - Jmabel ! talk 16:51, 14 December 2024 (UTC)