Commons:Village pump

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

Shortcut: COM:VP

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
Welcome to the Village pump

This page is used for discussions of the operations, technical issues, and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Archive/2021/11.

Please note:

  1. If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing, please do not comment here. It is probably pointless. One of Wikimedia Commons’ core principles is: "Only free content is allowed." This is a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias.
  2. Have you read our FAQ?
  3. For changing the name of a file, see Commons:File renaming.
  4. Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer).
  5. Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam.

Purposes which do not meet the scope of this page:

Search archives:

Broadwick St, Soho, London: a water pump with its handle removed commemorates Dr. John Snow's tracing of an 1854 cholera epidemic to the pump. [add]
Centralized discussion
See also: Village pump/Proposals • Archive

Template: View • Discuss  • Edit • Watch
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days.

November 09[edit]

COM:UDR instructions (or lack of)[edit]

Like I wrote at User talk:Contributers2020#Closing undeletion requests:

This is ridiculous. This is not the first time I have seen a non-admin close a UDR. COM:DR has clear instructions on who may or may not close a request. Why not just add a statement to COM:UDR?

No answer was provided there, so now I appeal to a wider audience. Brianjd (talk) 11:40, 9 November 2021 (UTC)[reply]

UDRs are less frequent than DRs. There is no pressing workload-based need for non-admins to close them. A non-admin cannot close a UDR leading to undeletion. So far we've seen no advantage to non-admins closing these, and they've attracted some editors whose judgement is widely questioned to start with.
So I'm against non-admins closing them. But we should make that clear. Andy Dingley (talk) 12:04, 9 November 2021 (UTC)[reply]
@Andy Dingley You're wrong here- Admins have backlogs to clear all COM:DR as well. They are seeing COM:AN as well plus the speedy deletion. Many instances at COM:HD admins solve the issues. COM:UDR is just a simple part of it. Contributers2020Talk to me here 14:02, 14 November 2021 (UTC)[reply]
  • We're talking about UDR, not DR. The backlog at UDR is 16, which is hardly a problem. Andy Dingley (talk) 16:04, 14 November 2021 (UTC)[reply]
    Bruh, i'm telling that administrators have much more backlog. UDR is literally like 1/20th of administrator backlog. When a UDR is heavily Symbol oppose vote.svg Oppose and is obvious that it will not be undeleted, what is the point for waiting for an administrator. Contributers2020Talk to me here 02:23, 15 November 2021 (UTC)[reply]
@Mysterymanblue Yeah Lol. But I wanted to also propose that if, in cases the user is just doing disruption in commons including that edit, or a rationale which just say nothing or something like abcdefglolllll, can non admins just speedy close the UDR. Contributers2020Talk to me here 06:23, 11 November 2021 (UTC)[reply]
no action should be reserved for certain users unless specific user rights are needed.
in this case the closure (the file remaining deleted) was legitamate and required no sysop tools. why waste the time letting it stay open and making several discussion threads about it? do you have nothing better to do? then start with Category:Commons backlog!--RZuo (talk) 19:03, 11 November 2021 (UTC)[reply]
That is so correct @RZuo. Contributers2020Talk to me here 10:46, 13 November 2021 (UTC)[reply]
Closing a request requires trust in the user deciding on it. Admins are supposed to be trusted, while other users have no formal qualifications for this (and usually cannot see the file, unless they were involved). Closures by untrusted users need to be reviewed by other people, and as there is no way to mark the closure as OK but by an admin signing it, there is absolutely no use in having the first, unqualified closure. –LPfi (talk) 17:55, 13 November 2021 (UTC)[reply]
  1. "admins" have no formal qualifications either.
  2. users are trusted, unless you think you should not be trusted by default.
  3. if being unable to see the deleted file could be an excuse to keep users from making informed decisions, then by the same logic they should be forbidden to comment on UDR at all. "you cannot see the file, what do you have to say about it?" RZuo (talk) 10:57, 14 November 2021 (UTC)[reply]
@RZuo: (2) You are not trusted by default; this is well-established by numerous policies, from blocking Tor editing to requiring legal agreements with the foundation for certain privileges.
(3) This is a false comparison. Commenting on the UDR only requires a user to have knowledge of some relevant aspect, whereas closing the UDR requires a user to have knowledge of all relevant aspects. Brianjd (talk) 11:11, 14 November 2021 (UTC)[reply]
  1. how does "blocking Tor editing" show that users are not trusted? by this logic users with IPBE (being able to use Tor) would be trusted and they should be allowed to perform actions like closing UDR?
  2. when did sysops have to have "legal agreements with the foundation for certain privileges"? should any of them without identity verification with WMF? and how does this show users are not trusted?
  3. where does that whole sentence "Commenting on the UDR... all relevant aspects." come from? did you just make it up?
  4. why would a non-sysop definitely not have knowledge of all aspects? why would a sysop definitely have knowledge of all aspects? how did you even assess their capabilities?
none of these bogus claims make any logical sense. RZuo (talk) 19:07, 24 November 2021 (UTC)[reply]
@RZuo (1-2) are responses to examples I gave. Just examples. Stop taking them out of context. Here's another example: We don't just hand out adminship; we require users to apply, and scrutinise them and vote on them. (3) I think that sentence stands for itself; accusing me of "mak[ing] it up" doesn't achieve anything. (4) A non-admin would usually not have knowledge of all aspects, as they would usually not have access to the file. An admin might also not have knowledge of all aspects, in which case they can choose to not respond, or ask questions, rather than close the request. Brianjd (talk) 04:43, 25 November 2021 (UTC)[reply]
  1. "Here's another example: We don't just hand out adminship; we require users to apply, and scrutinise them and vote on them." what does this example show? closing UDR as file remaining deleted requires no sysop rights.
  2. arguing by giving irrelevant examples is pointless.
  3. jokes on you -- very often a file can still be seen in google search or web archives, so that should mean users are allowed to close UDR then? your own incapability to assess deleted files is not a reason to block other users' sensible edits. RZuo (talk) 10:54, 1 December 2021 (UTC)[reply]
No new instructions have been added in COM:UDR. Is this discussion been concluded that non-admins have still the authority to close a UDR as not deleted?(of course we cant undelete them). Contributers2020Talk to me here 14:45, 19 November 2021 (UTC)[reply]
@Contributers2020 No admins have participated in this discussion either. I wonder whether we should take this to COM:AN. Brianjd (talk) 00:55, 20 November 2021 (UTC)[reply]
@Contributers2020: Stop digging.   — Jeff G. please ping or talk to me 01:51, 20 November 2021 (UTC)[reply]
How about a statement to the effect of "UDR is not the place to be bold"? Wait, that link says that you shouldn't be bold on Commons at all. Then why does my talk page have a welcome message that says: Be bold when contributing ...? Brianjd (talk) 02:51, 20 November 2021 (UTC)[reply]
Either way, @Brianjd, be bold, is just a advice/essay by a user. Even if we add this, the editor/user without admin privileges is not obliged to follow it. Also @Jeff G., what stop digging means? I am just asking whether yes or no and giving my concerns/opinions. Please maintain civility. And regarding no administrator responding, we can take it in AN as this discussion is on from 20 days. Contributers2020Talk to me here 11:33, 24 November 2021 (UTC)[reply]
@Contributers2020: You appear to be in a hole, and yet you keep digging. If you do not stop digging, you may not be able to escape the hole.   — Jeff G. please ping or talk to me 13:06, 24 November 2021 (UTC)[reply]
May I know why am I in a hole @Jeff G.? Contributers2020Talk to me here 13:39, 24 November 2021 (UTC)[reply]
@Contributers2020: You still post about wanting to close UDRs, when you've been told not to close requests by an Admin because you're really bad at it.   — Jeff G. please ping or talk to me 13:56, 24 November 2021 (UTC)[reply]
So @Jeff G. am I talking about just myself? Am I the whole non-admin in the universe? No, right? Even though I may do not close pretty non-obvious UDRs and DRs, other editors are there who are non-admins like you. Contributers2020Talk to me here 17:07, 24 November 2021 (UTC)[reply]
@Contributers2020: I haven't closed an UDR as not done in 15 months, and my closures were not questioned.   — Jeff G. please ping or talk to me 17:45, 24 November 2021 (UTC)[reply]
@Jeff G. Contributers2020 was told to stop closing DRs because they were bad at it. I don't remember anyone saying they were bad at closing UDRs. Brianjd (talk) 04:48, 25 November 2021 (UTC)[reply]
✓ Done Commons:Administrators' noticeboard#COM:UDR and non-admins. Pinging @Contributers2020. Brianjd (talk) 13:49, 24 November 2021 (UTC)[reply]
  • I'm neutral on it - On one hand a non-admin closing a blatantly obvious snow-oppose UDR would mean it'd be one less closure for an admin .... and it would also mean admins are being helped out with that backlog but then on the other are people going to close things where they shouldn't be closed (Ie would allowing non-admins to close these in the end be a bad idea?),
Although we're not EN WP:AFD gets on just fine with non-admin closures as far as I know although yes you do get some bad apples there too. Honestly on a trial basis I want to say give it a go see how everyone gets on, If people are making too many mistakes then revert back to admins only. –Davey2010Talk 14:37, 24 November 2021 (UTC)[reply]
@Davey2010 "Neutral" seems inconsistent with your use of {{S}} at Commons:Administrators' noticeboard#COM:UDR and non-admins. And this is COM:UDR, not COM:DR; they are treated differently for a reason, as discussed above; therefore w:WP:AFD might not be a valid example. Brianjd (talk) 04:46, 25 November 2021 (UTC)[reply]
Indeed I was leaning with support more than oppose but only by 1% which is why I noted I was neutral and supportive at the same time. Thanks for noting the fact this isn't DR - Perhaps if you bothered to read my entire comment you would've seen I stated "Although we're not EN WP:AFD gets on just fine with non-admin closures" so if I'm already aware we're not discussing DR then what's the purpose or point of telling me again ?" The very point to that comment was that non-admins close AFDs and most get on fine with it.
Lastly Brian nitpicking comments gets you nowhere in life - it's a shame you felt the need to nitpick every sentence - What did you achieve out of it ? .... Yeah quite literally nothing but well done if it's made you feel better about yourself!.
Symbol oppose vote.svg Oppose as per Gbawden and Taivo below. –Davey2010Talk 13:01, 25 November 2021 (UTC)[reply]
I agree with what AndyDingley said at the start. While I appreciate the sentiment of others wanting to help, the volume doesn't warrant it. And we can't afford to make mistakes at UDR. Gbawden (talk) 06:48, 25 November 2021 (UTC)[reply]
Symbol oppose vote.svg Oppose granting non-admins right to close UDR-s. Often this is last chance to make justice and we cannot allow here mistakes. Let's imagine, what happens, if a user complains: my photo was unfairly deleted, I filed a UDR and the guy who closed it wasn't even admin! If allowed, Contributers2020 will start to close UDR-s and this would be terrible. If you really want to help in UDR-s, please apply for administrator right. We are understaffed and any more-less competent user will pass. Taivo (talk) 11:39, 25 November 2021 (UTC)[reply]
The COM:AN discussion was archived; I consider both discussions as having a consensus against non-admins closing UDRs, but no meaningful discussion on adding instructions to COM:UDR (or COM:UNDEL). If no further discussion occurs, I intend to add a statement to COM:UNDEL (as that is where all the current instructions are) that non-admins should not close UDRs. Brianjd (talk) 09:49, 1 December 2021 (UTC)[reply]

November 21[edit]

SVG files rendering different colors in pages[edit]

Hi. I hope it's the correct place to discuss about that.
I realised that SVG files render a sensible different color in pages, e.g. the european flag in this page.
The file is set with offical RGB value given by european union for rendering on a screen, for the blue it's correctly rgb(0,51,153)    #003399    , even in the PNG preview like here or here (tested with a color picker too). But when you open this page, or another one with the file, and you pick up the color rendered, you see it's rgb(0,48,154)    #00309a    . (tested with multiples browsers)
I tested it with multiples files and u always have a difference. So is it a problem in the files i watched, or for all SVG files? Is there a way to fix it?
I know it's just a little difference, but what is the purpose to set an exact official value if the rendering is different? If it's a SVG problem, don't we have to chose another file type for important flags? --Harmonizator (talk) 07:38, 21 November 2021 (UTC)[reply]

@Harmonizator: I can confirm the same on Firefox 94. However the 255px thumbnail does show the correct colors:, but when the same image is displayed on the Wiki article both the blue and yellow stars are changed, blue as shown above and yellow from    #FFCC00     to    #FFCD00    . CSS overlayes could have this effect, but I couldn't find anything that would cause this. MKFI (talk) 08:18, 21 November 2021 (UTC)[reply]
Yes, sure. I maybe hadn't express myself good with my bad english, but yes it's for all colors, maybe except simple one like white, black, and pure red, green, blue and maybe pure cyan , magenta and yellow. (but i had'nt test it)
I also forget to say that this doesn't happend with PNG files. So, if it's not possible to fix it, maybe we should use PNG files or another type of files for flags or other things like this with an official value. --Harmonizator (talk) 09:24, 21 November 2021 (UTC)[reply]
PS: sorry, actually PNG files look to have a very poor quality.
This may after all be something browser-specific; if I copy the rendered PNG to an image editor it shows the correct colors, but if I open the same PNG in Firefox and take a screenshot I see the color change. With Internet Explorer colors do not change when I view the article. MKFI (talk) 10:12, 21 November 2021 (UTC)[reply]
Ha ha ! I didn't think to use Microsoft !
For me, the problem is the same with Microsoft Edge, but i have heard it's based on something common with chrome or Firefox. So you mean the real old Internet Explorer?
But it's strange cause in this diff, i saw color difference with the PNG, and it was before i discover the problem of the SVG rendering. --Harmonizator (talk) 12:00, 21 November 2021 (UTC)[reply]
PS: and after verification, the difference is exactly the same than the SVG rendering, but maybe it's cause i used an online tool to test the PNG file, so with my brower. I have to start to test files with an image editor.
Actually, for me most important is the rendering on Wikipedia, and i don't really care about what happends in Commons which is mostly for contributors. But I know anything about technics used, is what we see in Wikipedia only a PNG preview for an original SVG files? --Harmonizator (talk) 12:36, 21 November 2021 (UTC)[reply]
@Harmonizator and MKFI: off topic, you might want to make use of {{TTrgb}} next time. -- Tuválkin 22:30, 21 November 2021 (UTC)[reply]
I'm not sure what "The file is set with official RGB value given by European Union for rendering on a screen" means. Just the term "RGB" does not specify a standard color space. It does not tie the values to to specific CIE colors or an ICC color profile (see w:en:ICC profile). Often RGB means the device color space — the numbers sent to the device to control the primaries' intensities. Different devices display different colors when given the same device RGB values. Cathode ray tubes work differently from flat panel technology. Even within the same technology, the displayed colors for the same RGB values may differ.
In order to get consistent color displays, individual devices may be calibrated/color corrected. That means that desired RGB values are mapped into new R′G′B′ values to show the desired color. There are instruments to do color calibrations. A simpler approach just assumes that all Model XYZ screens will have similar characteristics so they can share a common color correction.
SVG uses the sRGB color space. See w:en:sRGB. The sRGB color space does expect a particular sRGB to display a particular CIE color. However, the sRGB color space requires mapping to a particular device's RGB values (a color correction) to achieve that goal.
Here is what happens. The color specification in SVG is sRGB. The SVG agent uses some color correction routines to map sRGB values into device RGB values to get the specified sRGB color. Those are the values that are sent to the screen. When you do a screen capture, you obtain an array of the device's RGB values (not the original sRGB values). The number differences that you see are the color corrections.
PNG files can give different results. I believe the ordinary PNG file does not imply any color profile so its RGB values are just sent to the screen without any color correction. Such a file would look different on different device technologies. PNG files have the ability to specify that they use sRGB or some other color profile (see w:en:Portable Network Graphics), but I suspect the PNG files you tried did not do that. If the PNG does not do any color correction, then the values sent to the device are the RGB values and those values would be in the screen capture.
When an SVG file is included in a wiki article, the SVG file is not sent to the user. Instead, the SVG file is converted to a PNG file, and the PNG file is displayed on the page. Presumably, the PNG file would use the sRGB color space, so the RGB triples in the PNG file would match those in the SVG file (note that the agent rendering the SVG image has no idea about the ultimate user's color space, so it must use a standard color space). It's possible that the render sets the PNG flag to say it is sRGB, so the screen captured RGB values would be the color corrected values.
Glrx (talk) 16:15, 21 November 2021 (UTC)[reply]
@Glrx: Looks like you know exactly what Harmonizator’s sentence («official RGB value given by European Union for rendering on a screen») means — you just think it is incorrect to issue an sRGB triplet as a colorimetric standard, fair enough, and then you try to obfuscate the matter with a wall of text nobody asked for.
The matter is that sRGB triplets stated in the source SGV files are not being transposed one-to-one onto the PNG thumbnails generated on the fly by Wikimedia software, being instead altered through an undocumented color correction algorithm. Looks like you think this is a good idea, while Harmonizator and others might think it’s a bad idea. I for one want to know where documentation about this can be read. (I confess I’ll be mainly looking for its off-button, but always keen on reading about this stuff.)
-- Tuválkin 22:25, 21 November 2021 (UTC)[reply]
I have no idea what the EU wants. A claim was made, but no source was given. I have no problem with colormetrics specified with sRGB values, but the OP just said RGB (not sRGB). It is likely the EU means sRGB, but I do not know that they did.
"The matter is that sRGB triplets stated in the source SGV files are not being transposed one-to-one onto the PNG thumbnails generated on the fly by Wikimedia software." That does not fit the facts above. Harmonizator said the triples in the SVG file and its PNG rasterization are the correct ones. I did not go poking around in either file to check that assertion, but it is logical that the triples are the same. The PNG is the result of WMF using librsvg to process the SVG file. If the triples are the same, then libsrvg processed the colors correctly. The only issue is whether librsvg set the sRGB flag in the PNG output. Given Harmonizator's story, I believe librsvg set that flag. When browsers display the SVG or the PNG, then they should use the sRGB color space.
I would expect the color picker in a graphics editor to provide the sRGB values specified in the SVG or the PNG. It does not make sense to do anything else.
The problem is the screen grab. I would expect that to obtain the device RGB values from the screen buffer. A screen grab would not know about any color transformations that were made. I would expect that the inverse sRGB transformation on the screen buffer triples would be close to the original sRGB values.
Who said it is an "undocumented transform"? The sRGB color space is well defined. The display you are using right now should be stable. All the transform does is map the given sRGB triples to the triples your display needs to best approximate the sRGB triple. It is not a 1:1 mapping because different displays use different primaries, different gammas, and other different properties.
There is plenty of information about color space transformations. There are also operating system calls to control the transformations. For Windows, see the documentation and concepts. In Windows, a programmer would setICMMode(ICM_ON) to enable color transformations before writing sRGB triples to the display. If ICM_OFF, then device RGB space is used. A screen grabber has access to the color buffer, but it does not know which mode was used to write the pixels.
Glrx (talk) 00:08, 22 November 2021 (UTC)[reply]
This is going too technical for me, but i wanna give this precisions:
  • I never make any screenshot to pick up the rendered colors, I use live color picker extensions, and different ones which give me the same result.
  • Even if it's not the subject, European Union gives this official recommandation for RGB values here, and since 2004 and maybe more. --Harmonizator (talk) 09:22, 22 November 2021 (UTC)[reply]

So, the EU gives an official recommandation to render the colors of the flag on a screen, and it's visible in all its website. But when you go on Wikipedia, you don't have this correct colors because of this SVG rendering problem. So, I think we have this solutions:

  • Give a correct SVG file if the problem is in the file used, and not general for any SVG.
  • Correct the way MediaWiki uses to render SVG files on Wikipedia if it's a general problem for all SVG files.
  • Or stop to use SVG files on Wikipedia when we try to give a specific RGB value, for this files or others. (and so this will be a discussion on Wikipedia) --Harmonizator (talk) 09:24, 22 November 2021 (UTC)[reply]
I understand your point but I wouldn't do anything about it. The issue it's causing doesn't warrant replacing hundreds to thousands of files or doing something to the MediaWiki. There are known issues with the render software that actually break the file, this is "huh, interesting", the difference is miniscule, smaller than the difference between the same colour on any two office-level computer screens. TFerenczy (talk) 17:56, 22 November 2021 (UTC)[reply]
Yes, sure. Maybe all this color things on flags begins to drive me crazy actually. ;)
And actually, the europen flag is the only one I know that have an official special RGB value, so I wasn't talking about thousands pages, maybe just some pictures to illustrate colors.
And, as I said, i don't know anything about the technical part. So if it's complicated, that's not really a problem.
But it's a strange thing to observe, and if they're is a possibility to correct it, it will be welcome. --Harmonizator (talk) 04:21, 23 November 2021 (UTC)[reply]
I checked this some more and now I am even more confused: on en:Flag of Europe I see the color change described above, but on de:Europaflagge the colors are correct. I note that this is quite old file, and the articles use different sized thumbnails. Could the problem be that over the years thumbnails have been generated with different image magick versions? MKFI (talk) 10:57, 23 November 2021 (UTC)[reply]
Is this correct too? That's a direct link to the png thumbnail used at en:Flag of Europe. If that is OK on its own (i.e. outside the article), rendering the png from SVG cannot be the problem and the actual problem must be somewhere later in the pipe line. Maybe en:Template:Infobox flag, en:Template:Infobox, or whatever comes next does something to the image files? --El Grafo (talk) 12:16, 23 November 2021 (UTC)[reply]
@El Grafo: the generated thumbnails are correct; somehow it just displays incorrectly in en:Flag of Europe. MKFI (talk) 14:31, 26 November 2021 (UTC)[reply]
Flag of Europe.svg
@MKFI OK, that's good, I guess. Two more things we can check (sorry for asking, I don't have the proper tools for this available at the moment):
1) Is the version over here on the right OK? That would be a hint that the problem may lie at Wikipedia in particular, not Mediawiki in genreal
2) Is the version at the bottom of the table right above en:Flag_of_Europe#1983–present:_From_European_Communities_to_European_Union OK? That would be a hint that it's not a general problem at en.wikipedia but a more specific problem with image display inside of infobox templates.
Once that's clear we can think about where to find somebody who knows enough about the respective internals to find the actual root of all this … – El Grafo (talk) 15:39, 26 November 2021 (UTC)[reply]
@El Grafo: the vertical tall flag displays correctly, but the version with E has the same color problem - but now the infobox image showed correctly! @Harmonizator: does the infobox image on en:Flag of Europe show up correctly to you now? MKFI (talk) 07:59, 27 November 2021 (UTC)[reply]

The reference Annex A1 states the colors are

  • The colours of the emblem are Pantone Reflex Blue for the surface of the rectangle and Pantone Yellow for the stars. The international Pantone range is very widely available and easily accessible, even for non-professionals.

That defines the colors. The given history has the flag designed in 1955 as gold stars on a blue background. Pantone did not appear until 1963. The Annex states

  • Pantone Reflex Blue corresponds to the web-palette colour RGB: 0/51/153 (hexadecimal: 003399) and Pantone Yellow corresponds to the web-palette colour RGB: 255/204/0 (hexadecimal: FFCC00).

The SVG file uses fill="#039" and fill="#fc0". The CSS color spec says that is shorthand for fill="#003399" and fill="#ffcc00", so the colors are properly specified. There is nothing wrong with the SVG file, but SVG does use sRGB. On a Windows machine, I can press Print Screen to copy the screen to the clipboard, I can paste the image into the Paint application, use the color picker tool to select a pixel, and then click Edit Colors to learn the RGB value. If I do those steps on displayed in the Edge or Firefox browser, then I get the values

  • 0,51,153
  • 255,204,0

Those are the Annex values (but they are not the values that I expected; I expected slightly different color-corrected values). That suggests the browsers do not apply sRGB color correction to SVG files. If I download (a file made by librsvg and open the file directly with Paint, the color picker within Paint gives me the color values stated in the Annex. (I expected those values.) That suggests that librsvg generates color-appropriate PNG files. If I display the wiki pages,,, and in Edge or Firefox, do Print Screen, and examine the clipboard values with Paint, then I get the RGB values

  • 0,48,154
  • 255,205,0

Those match the odd values reported above, and I expected them to be slightly different than the Annex values due to color correction. All three files were rendered by librsvg into PNG files and then displayed in a Browser, so I would expect them to be consistent. That suggests the browsers apply color correction when they display PNG files. I did not check whether the PNG files were setting a color profile. Glrx (talk) 00:33, 27 November 2021 (UTC)[reply]

November 24[edit]

Responsibility towards other projects[edit]

Metre Convention Signatories
  Member states
  Associate member states
  Former member states
  Former associate member states (new category)

There are times when a Commons editor modifies an existing image that potentially affects other Wikimedia projects. For example, until recently, File:Metre_Convention_Signatories.svg identified three types of country - full member states, associate member states and former member states. This file was recently upgraded to include former associate member states. (See image to the right). This upgarded image will automatically and silently find its way into every Wikimedia project where it is used (as is done here). Many projects list the meaning of the colours in the caption to the image, but when this update is done, those projects are not notified that they might need to revisit the articles where they are used and explain the meaining of the countries that are coloured light green.

My question is "Whose responsibility is it to ensure that the various projects keep their captions in synchronisation with updated image? Does it lie with the Commons editor (who has made the action that causes the changes) or does it lie with the team that run the recipient project? If it is the latter, how are they expected to become aware of the changes?

Martinvl (talk) 17:51, 25 November 2021 (UTC)[reply]

Strictly speaking such widely used files should not be overwritten with new significantly different new versions. Ruslik (talk) 20:25, 25 November 2021 (UTC)[reply]
While I generally agree with Ruslik, in the real world organisations evolve continually with the result that such files have small modifications once or twice a year while occasionally (maybe once every five to ten years) it is neccessary to introduce a significant change to the file, such as in the example given. There is also the problem that in certain Wikimedia projects, the caption includes information, for example a date, which will be invalidated by the new file. Martinvl (talk) 21:41, 25 November 2021 (UTC)[reply]
@Martinvl, have you seen the COM:Overwriting existing files guideline, particularly regarding files that do not contain the {{Current}} template. It seems that File:Metre Convention Signatories.svg should never have been updated, but rather the new versions created as new files. -- DeFacto (talk). 10:17, 30 November 2021 (UTC)[reply]
@DeFacto: Thanks - I was not aware of that particular template. Martinvl (talk) 11:58, 30 November 2021 (UTC)[reply]
@Martinvl: Please sign your posts with four tildes, so that your signature includes the timestamp. I have added it for you.
COM:Overwriting existing files, mentioned above, clearly states that it is not OK to overwrite files with the following:
Changes that reflect different data (e.g. updating a map), where the file has not been marked as updateable
It is clear that this file should not have been overwritten. I am not sure whether simply marking it as updateable now is acceptable. I see no discussion on the file's talk page. Did you discuss this with other users? Brianjd (talk) 12:36, 30 November 2021 (UTC)[reply]
Pinging @Ruslik0, DeFacto. Brianjd (talk) 12:37, 30 November 2021 (UTC)[reply]
I'd say that once it's in use, a file should not have the template added retrospectively, as it was used in good faith as being non-updatable. A solution might be to revert it back to the original state and create a new, updatable version of the file, and add subsequent amendments there. -- DeFacto (talk). 14:14, 30 November 2021 (UTC)[reply]
The file itself has the template {{NoInkscape}} embedded in it. This template was added by the original editor @Getsnoopy: before any other editor had made any contributions to the file. This tells me that it was always the intention of the original editor that the file should be updated so as to reflect the current situation. I have initiated a discussion on the file's Talk Page in which I have requested that the original editor confirm his intentions. Martinvl (talk) 14:28, 30 November 2021 (UTC)[reply]
User:Getsnoopy has since confirmed that it was his intention that the file should be updated as and when necessary. Martinvl (talk) 22:04, 30 November 2021 (UTC)[reply]
@Martinvl, @Getsnoopy, adding the {{Current}} retrospectively, more than 2 years after the file was created in this case, doesn't really answer the question raised at the start of this thread though. It still stands as: if the 'current' template is added to an image after it has been used without it, whose responsibility is it to ensure that the various projects that used it before the current template was added, keep their captions in synchronisation with updated image? -- DeFacto (talk). 07:17, 1 December 2021 (UTC)[reply]
@DeFacto: I'm assuming you're referring to the cases where the caption itself has a legend or the like, in which case it would need to be updated (by the maintainers of the page and/or the person updating the image). In many cases that I've seen, however, the caption only has a description and clicking on the image opens the media viewer which loads the image description from Wiki Commons, which would have the legend in the appropriate language, etc. Getsnoopy (talk) 07:24, 1 December 2021 (UTC)[reply]
@DeFacto The question doesn't really make sense. It is asking who is responsible for fixing the captions after an image is updated, when a Commons guideline clearly states that the image should not have been updated at all. As a general principle, whoever breaks the rules needs to clean up their damage, so I would say: "the Commons editor". But if the captions that need updating are in different languages, this might not be practical. And I'm strongly opposed to Commons contributors messing with other projects, unless they happen to be active there. So I think there is no good answer to your question. Brianjd (talk) 07:36, 1 December 2021 (UTC)[reply]
I agree with you @Brianjd that the "do not update" rule has been broken, but it seems that @Martinvl and @Getsnoopy think they have rectified that by retrospectively adding the {{Current}} template. That still leaves the original problem of the maintenance of previous uses. This could be a major problem in an article about the position at a particular date. I think each update should be made in a new file with an "as of ..." date in the title, and perhaps a 'current' version of the file too (containing the {{Current}} template) which could be chosen by editors for articles that need to always show the latest condiditon. -- DeFacto (talk). 09:26, 1 December 2021 (UTC)[reply]

November 26[edit]

File picking up wrong description, presumable from wikidata[edit]

This file is picking up wrong info from somewhere. I assume it's from Wikidata, but after deleting the image from the indicated Wikidata item the info still appears. The file is a painting of a woman reading, but the title shown is "A Village Street with a Performing Bear"; that painting looks nothing like this. Can someone help? --Auntof6 (talk) 02:18, 26 November 2021 (UTC)[reply]

This file is having a similar problem. It's interesting that both paintings are by the same artist, and the incorrect ones they point to are by the same other artist. --Auntof6 (talk) 02:20, 26 November 2021 (UTC)[reply]
@Auntof6: It is the structured data within Commons, which is also built on Wikibase, but is not Wikidata. I'll just delete the wrong information. Someone else can either add correct information or not. - Jmabel ! talk 17:53, 26 November 2021 (UTC)[reply]
Oh, dear, that certainly didn't work. The whole thing seems based on an {{Artwork}} template that relies on structured data! The is exactly the sort of thing that makes some of us VERY unhappy with structured data on Commons. - Jmabel ! talk 17:57, 26 November 2021 (UTC)[reply]
(after 2 edit conflicts) @Multichill: It looks like both files were uploaded on Commons by your bot last year and linked to the wrong wikidata items in the first edit.[1][2] Both files were uploaded within a day of each other. Are you able to see what went wrong here? I am assuming it was a couple of blips in a batch edit but are you able to tell if any more need fixing?
Jmabel, this is not a Wikidata or structured data problem. It looks like an error in a bot edit. That could happen whether Wikidata was involved or not. From Hill To Shore (talk) 18:05, 26 November 2021 (UTC)[reply]
@From Hill To Shore: but if it were normal Wikitext, it would be much clearer how to fix it. - Jmabel ! talk 19:59, 26 November 2021 (UTC)[reply]

@Multichill: Looks like File:Rex Whistler (1905-1944) - Lady Caroline Paget (1913–1976), Later Lady Duff - 1176330 - National Trust.jpg was totally misidentified in the structured data, and that the way it was described in the wikitext is completely dependent on the structured data. I removed the incorrect structured data, and it basically all went to hell. Since the actual artist only died in 1944, I'm not at all sure this is even public domain.

Apparently similar issues for File:Rex Whistler (1905-1944) - Lady Caroline Paget (1913–1976), Later Lady Duff - 1176331 - National Trust.jpg, which I haven't touched. - Jmabel ! talk 18:02, 26 November 2021 (UTC)[reply]

I've worked out the source of the problem. Art UK and National Trust have got their wires crossed. The Art UK page with a female portrait[3] gives the National Trust reference as 1176330 but when you check that reference at the National Trust website you get a different painting about a performing bear.[4] The bot has performed correctly and collected the linked data from both websites. This is neither the fault of Multichill or Wikidata but the source. I'll have a go at editing Wikidata and the two files to repair the issue. From Hill To Shore (talk) 18:21, 26 November 2021 (UTC)[reply]
{{Artwork}} accepts a parameter |wikidata= where you can link the wikidata entry for the painting. That's what I've done now for File:Rex Whistler (1905-1944) - Lady Caroline Paget (1913–1976), Later Lady Duff - 1176330 - National Trust.jpg and it seems to work. The only concern there is the US copyright status. De728631 (talk) 18:27, 26 November 2021 (UTC)[reply]

Thanks, all. --Auntof6 (talk) 20:49, 26 November 2021 (UTC)[reply]

@From Hill To Shore: exactly. Lady Caroline Paget, Lady Duff (1913 -1976) (Q52256027) & A Village Street with a Performing Bear (Q52255990) (and the other pair) got mixed up because ArtUk mixed up the inventory numbers. My bot would normally never upload files like these and I deleted them. Multichill (talk) 16:27, 27 November 2021 (UTC)[reply]

File:Baby Krishna 2.jpg[edit]

File:Baby Krishna 2.jpg

Is this image in the Public Domain? Google Search reveals that has been around on the web for some time. Uploader claims that "The Infant w:Krishna photograph posted here is the artistic and symbolic picture of Lord Krishna. It is very old and its source cannot be obtained". Perhaps someone here with greater knowledge than me of images of the infant Krishna could confirm or deny? It is in use, by the way, and its a nice picture, albeit low definition, so it would be good to keep if we can.--Headlock0225 (talk) 13:57, 26 November 2021 (UTC)[reply]

Reverse image search finds a larger version with different colors, but that's as far as I got. --El Grafo (talk) 16:13, 26 November 2021 (UTC)[reply]

With the lack of information of the artist, or when or where it was published,reluctantly, I think I will nominate for deletion and see where that takes us. If it was in the public domain your source, El Grafo, is much better quality! --Headlock0225 (talk) 12:02, 27 November 2021 (UTC)[reply]

Talk to the Community Tech: The future of the Community Wishlist Survey[edit]

Magic Wand Icon 229981 Color Flipped.svg


We, the team working on the Community Wishlist Survey, would like to invite you to an online meeting with us. It will take place on 30 November (Tuesday), 18:00 UTC on Zoom, and will last an hour. Click here to join.


  • Changes to the Community Wishlist Survey 2022. Help us decide.
  • Become a Community Wishlist Survey Ambassador. Help us spread the word about the CWS in your community.
  • Questions and answers


The meeting will not be recorded or streamed. Notes without attribution will be taken and published on Meta-Wiki. The presentation (all points in the agenda except for the questions and answers) will be given in English.

We can answer questions asked in English, French, Polish, Spanish, German, and Italian. If you would like to ask questions in advance, add them on the Community Wishlist Survey talk page or send to

Natalia Rodriguez (the Community Tech manager) will be hosting this meeting.

Invitation link

We hope to see you! SGrabarczuk (WMF) (talk) 20:03, 26 November 2021 (UTC)[reply]

  • Here’s my tech wish: Not having server outages like we had just now. -- Tuválkin 19:20, 29 November 2021 (UTC)[reply]
    @Tuvalkin, I hear we're being DDoS'ed. I don't know if we can make us immune to that but you surely can talk to us about what else is your wish :) SGrabarczuk (WMF) (talk) 20:19, 29 November 2021 (UTC)[reply]
  • @SGrabarczuk (WMF): the time above appears to be wrong. It is presently 17:05 UTC, but when trying to join the meeting Zoom says it is scheduled for 18:00 UTC. — Rhododendrites talk |  17:05, 30 November 2021 (UTC)[reply]
    Yes, it's my fault. It should be 18:00. Thank you @Rhododendrites! SGrabarczuk (WMF) (talk) 17:17, 30 November 2021 (UTC)[reply]

November 28[edit]

Created a template for PD collection at Library of Congress but unclear on one part[edit]

Hello. I just created this template, PD-Angel, for a public domain collection from the Library of Congress, copying another template that I'd been using for a different collection (example image). However, the part where it says "This template will categorize into Category:PD-Angel." that category is a red link, and I'm not sure how categories in WC are created and I maybe missed a step? Do I need to request this or ask someone with more privs than me? Any help would be appreciated, thank you. Jessamyn (talk) 02:01, 28 November 2021 (UTC)[reply]

I believe I have answered my own question and will read up on the tutorial. Jessamyn (talk) 03:31, 28 November 2021 (UTC)[reply]

File picking up unneeded categories from parent category[edit]

File:La Place du Châtelet by Étienne Bouhot (Carnavalet P 1286) 01.jpg is showing categories that are on the specific category for this painting, Category:La Place du Châtelet by Étienne Bouhot (Carnavalet P 1286). They seem to be coming from something in the text for the file, because when I delete everything in the file the extra categories go away. Can someone help eliminate the extra categories? Thanks. --Auntof6 (talk) 03:26, 28 November 2021 (UTC)[reply]

I have converted the description template from {{Object photo}} to the more commonly used {{Artwork}}, which does not have that problem, while still calling all relevant information. --HyperGaruda (talk) 11:22, 28 November 2021 (UTC)[reply]
P.S. {{Object photo}} would have probably functioned properly with that file if the relevant category had contained {{Category definition: Object}}. --HyperGaruda (talk) 11:30, 28 November 2021 (UTC)[reply]
@HyperGaruda Thanks. -- Auntof6 (talk) 14:07, 28 November 2021 (UTC)[reply]

November 29[edit]

Intimate images without subject's consent[edit]

When I say "intimate images", I am referring to images of genitals, buttocks or breasts, where there is a reasonable expectation of privacy. This appears to be the case in Commons:Deletion requests/Files uploaded by Matt Bio Research, and I cannot believe what I am seeing there: one user is arguing that these images are OK because just because they are not "identifiable". I argued that there is doubt as to whether the subjects consented, and the other user has not disputed this: they are simply pressing on with the identifiability argument. I am not convinced that distributing these images is even legal.

The only thing more shocking than that discussion is the fact that we don't have a policy on this. Brianjd (talk) 04:03, 29 November 2021 (UTC)[reply]

Unidentified photographs of paintings at the Salar Jung Museum[edit]

Salar Jung Museum - Beautiful Art 4.jpg
Salar Jung Museum - Beautiful Art 3.jpg

I almost put this image up for deletion. It's probably a low-quality photograph of a public domain painting. As it is, we lack enough information to tell whether it's public domain or where it might be of some little educational use, leaving it out of scope. Anyone want to take a shot at salvaging it with painter, title and date?--Prosfilaes (talk) 18:53, 29 November 2021 (UTC)[reply]

Salar Jung Museum - Beautiful Art 1.jpg
Salar Jung Museum - Beautiful Art 2.jpg
And let's add three more, some of which have more serious concerns of public domain nature.--Prosfilaes (talk) 18:57, 29 November 2021 (UTC)[reply]
Here are the museum's own photos of two of these (not eligible for Commons because they are unlicenced photos of the 3-dimensional frames); they don't identify them anywhere obvious (I got there from
Jmabel ! talk 21:25, 29 November 2021 (UTC)[reply]
Uploader User:NAGASREENIVASARAO PUPPALA hasn't been active in years, and was only briefly active, so not a lot of chance of hearing from him. - Jmabel ! talk 21:27, 29 November 2021 (UTC)[reply]


By chance I noticed the following for which I have no explanation. In the history of File:Nora Grace Skam.png is mentioned on 2021 jul 23 14:36‎ "[es] bijschrift toegevoegd: Foto de Nora Skam España. Interpretada por Nicole Wallace". In the edit mode I don't see "Nicole Wallace" anywhere. Where has that gone? Wouter (talk) 21:35, 29 November 2021 (UTC)[reply]

  • @Wouterhagens: It's a Spanish-language structured data caption. It's there, but it's not wikitext. - Jmabel ! talk 00:34, 30 November 2021 (UTC)[reply]
    • @Jmabel: Thanks, but can this be made visible? When I add ?uselang=es to the image URL, I don't see any extra info under "Datos estructurados". When I want to create a new category, I check with a search whether there are more images that make it worth creating the category. So I got to the image with this search. Such a search yields more information than I can gather from the description. Wouter (talk) 12:50, 30 November 2021 (UTC)[reply]
      • @Wouterhagens: I know, and I completely sympathize. One of several ways I find structured data on Commons a mess. It shows up not in the "structured data" section, but the "file information" section. Depending on your settings and your skin you may see it different ways; for me, there is a box at at the top of the "file information" section that says, "[Expand]". If I click on that, I see the captions. - Jmabel ! talk 18:47, 30 November 2021 (UTC)[reply]
        Thanks, I found it! Wouter (talk) 19:15, 30 November 2021 (UTC)[reply]

November 30[edit]

Issue about the Science Wiki 2022 contest[edit]

I received an invitation to participate in Wiki Science 2022 and so I uploaded my images by following the links proposed on the competition page for the Italian section. At the end of the upload, however, all the set of images uploaded showed the logo for participation in the 2019 competition. I reported the problem but to date I have not received any answers. So I don't know if I have to reload the images in the world section rather than again in the Italian one. Thanks in advance to anyone who can help me solve the problem — Preceding unsigned comment added by Buiobuione (talk • contribs) 08:56, 30 November 2021‎ (UTC)[reply]

@Alexmar983: Ciell (talk) 09:25, 30 November 2021 (UTC)[reply]
@Buiobuione: Hi, and welcome. I see User talk:Buiobuione#Wiki Science Competition 2021 has started. From there, I follow the "this page" link to Commons:Wiki Science Competition 2021. I see that this edit in Italian mentions Italy, so I look for Italy there, but do not see it in Commons:Wiki Science Competition 2021#National competitions, so I click "have specific national juries". At the bottom of that page, I see a mention of Italy with a circular upload link. I go back to Commons:Wiki Science Competition 2021#National competitions and instead click the "here" link in "All of the upload forms can be accessed from here" to Commons:Wiki Science Competition upload. On that page, I click link "Italy" to, and use that to upload File:Galaxy (8704358643).jpg, which gets the right logo but wrong description from "{{Wiki Science Competition 2019|it}}". I change "2019" to "2021" in this edit, and all is well; thus, the problem is in how the competition is set up. Then, because I am not the photographer I change to account for that in this other edit. See also COM:SIGN. PS: It's not 2022 yet.   — Jeff G. please ping or talk to me 10:23, 30 November 2021 (UTC)[reply]
User:Buiobuione you did not receive any answer because you did not tag or write in the talk page of the competition... I cannot check 1000s of talk pages. BTW, Italy has no national competition this year, but since it has a lot of upload we created a national category, to simplify the evaluation. I asked User:Reosarevok to update the interface to simplify the categorization process which he did here and he probably forgot to update some templates somewhere.I asked him to double check just in case.
There are no circular link BTW. You have national competitions with some specific descriptions, you have a miscellaneous category for the rest of the world and you have a specific upload for some countries that have no national jury, no national prizes but still can be sent quickly to a specific category.--Alexmar983 (talk) 11:27, 30 November 2021 (UTC)[reply]
Scusami se non ho taggato o scritto nella pagina principale, non so ancora usare wiki nel modo corretto, sto imparando. Spero quindi che il problema si risolva con gli interventi da te indicati e che non sia necessario ricaricare le immagini. Grazie ancora per la risposta Buiobuione (talk) 12:02, 30 November 2021 (UTC)[reply]
Buiobuione risolto tutto. Essendo un set di buona qualità e non essendoci concorrenza finiranno probabilmente secche alla finale internazionale. Ribadisco: l'Italia non ha un concorso nazionale, ma essendoci abbastanza foto di origine italiana le ho comunque scorporate da "resto del mondo", quindi per chi partecipa la competizione è minore, e le chance di diventare finalista nazionale e quindi accedere alla finale internazionale più alte comunque. Non ci sono al momento altri set di immagini caricati dall'Italia.--Alexmar983 (talk) 12:22, 30 November 2021 (UTC)[reply]
grazie ancora Buiobuione (talk) 13:02, 30 November 2021 (UTC)[reply]

Wikimedia Sound Logo project[edit]

Hello everyone,

The Wikimedia sound logo project is in an early development phase -- this stage is for asking all kinds of questions, developing and fielding ideas, finding themes and shaping the direction of the project. Here is a link to the meta page for the project:

Your input is welcome. Thank you, VGrigas (WMF) (talk) 14:40, 30 November 2021 (UTC)[reply]

Category:Linguistic maps of Algic languages[edit]

Looks like the catogory has a lot of duplicates. 20:03, 30 November 2021 (UTC)[reply]

  • Doesn't look that way to me. Similar maps, one with and one without modern borders, are not duplicates. Not to say that there couldn't be a duplicate somewhere in here, but it didn't leap out at me. - Jmabel ! talk 01:21, 1 December 2021 (UTC)[reply]

December 01[edit]

Remove visual editor[edit]

Hello. A few minutes I noticed that my edit window changed to VisualEditor. I was adding a gadget so I very well may have caused this. Is it possible to revert back to the old edit window, and if yes, how? I find the visual editor very clunky and requiring a lot more clicks. This is IMO inadequate for categorization work in Commons. Thanks. Cryptic-waveform (talk) 00:40, 1 December 2021 (UTC)[reply]

In the beta tab, untick Visual Editor and click on Save. Bidgee (talk) 00:58, 1 December 2021 (UTC)[reply]
Thanks! That did it. Cryptic-waveform (talk) 01:07, 1 December 2021 (UTC)[reply]

Backlog of deletion requests[edit]

On Wikipedia I noticed a user added an image which I recognised as being a scan from a book. Seeing it had been uploaded to Commons and assuming this was the correct process, I clicked "request deletion" (see Commons:Deletion requests/File:Albert Park Circuit 1950s.jpg for details). I noticed the same user had uploaded several files from a website which it would appear doesn't allow reproduction without permission, so I again requested deletion (see Commons:Deletion requests/File:Surfers Paradise Raceway.svg for details and the other files). But having checked back I see no-one has commented on these discussions, and indeed there is a backlog of months of files which haven't been discussed. I don't mean to appear rude, but for potentially copyrighted material this doesn't seem good enough. I know I probably should have tagged them for speedy deletion instead but I don't think that is permitted once a deletion request is opened? The same user also uploaded File:Wuhan Street Circuit.png and File:Circuit Pau-Arnos.png in apparent breach of the Ts&Cs of [5] (see also their talk page User talk:Apeiro94#File:Adria Circuit 2021.png where a file was deleted which had been taken from the same website) and also there is File:Charlotte Roval.png which is in breach of another websites Ts&Cs [6]. Thankyou for your assistance. A7V2 (talk) 21:49, 1 December 2021 (UTC)[reply]

Deletion Requests (DR) are open for a minimum of 7 days, for clear copyright violations, you should have used {{Copyvio}} and only use DR when copyright is uncertain. Bidgee (talk) 22:04, 1 December 2021 (UTC)[reply]
@Bidgee Actually, I understand that non-controversial requests can be closed earlier (as keep, by any user; or as delete, by an administrator), provided that someone actually sees them. This is particularly true for copyright violations; Commons:Deletion requests#Closing discussions says:
Deletion requests for obvious copyright violations can be closed earlier. Brianjd (talk) 02:46, 2 December 2021 (UTC)[reply]
@Apeiro94: as uploader. @A7V2: since there was a response with no ping. - Jmabel ! talk 23:09, 1 December 2021 (UTC)[reply]
@Jmabel: You might be interested in {{Pinging}}.   — Jeff G. please ping or talk to me 23:14, 1 December 2021 (UTC)[reply]
We are in need of more admins. I am working on some of the oldest DRs, from February 2021, but the backlog is not decreasing or too slow to notice. See COM:ADMIN for tasks and procedures to get involved. Ellywa (talk) 23:18, 1 December 2021 (UTC)[reply]
Yes with only 204 admins (and assuming not all are going to be active) it seems like a LOT of time would be needed. Probably people not being particularly comfortable or familiar with copyright and such would be a problem too. Given it's true I should have tagged for speedy deletion instead, is that still an option now that I've requested deletion? I will tag all the other files I've mentioned now. Thanks. A7V2 (talk) 00:35, 2 December 2021 (UTC)[reply]
@Bidgee I see many files that are eligible for speedy deletion that are instead nominated for normal deletion. Normally the reason is G7, but sometimes F1, and rarely other reasons. I also want to know if I can tag these files for speedy deletion after a normal deletion request has been started. Brianjd (talk) 02:41, 2 December 2021 (UTC)[reply]
@Brianjd: I have added tags to the two pages I opened a deletion discussion for. I don't think there's any benefit waiting to delete clear cases of copyright. My thinking is that the original copyright holder shouldn't have to have their work here for longer than necessary due to someone here's mistake (me in this case). If it's not allowed, it probably should be! A7V2 (talk) 23:33, 2 December 2021 (UTC)[reply]
@Brianjd: Yes, non-controversial DR can be closed before 7 days but that tends to be for clear case copyright violations. Bidgee (talk) 03:04, 3 December 2021 (UTC)[reply]

Many coloured ligths[edit]

Granollers Centre station 2021 3.jpg

Any idea what these ligths are used for?Smiley.toerist (talk) 23:13, 1 December 2021 (UTC)[reply]

December 02[edit]

Category:Free emulation software Copyright and PD issues in 74 categories.[edit]

Category:Free emulation software Copyright and PD issues in 74 categories.

In files in the free emulation software category,

In 74 categories from A to Z,

Some files contain copyrights and PDs.

Copyright without the owner's permission and files with PD's permission

It's being left unattended.

The files are in Korean, Japanese, English, Chinese, German, Russian, French, and Italian.

In numerous documents, uploaded public files are being used without copyright discussion.


Free emulation software (Category)

Subcategories This category has the following 74 subcategories, out of 74 total.

Free emulation software has 74 categories.

Duckstation, Joiplay, Redream, etc. that have been confirmed to be deleted.

Three needs to be deleted along with the category.

I think we need to consider whether to preserve or delete the remaining categories left empty.

Among these categories, it is important to check whether the uploaded files have copyrights and PDs.

There are dozens of files that need to be deleted and left unattended.

From 1964 (emulator) to ZSNES, we'll investigate everything in alphabetical order (A to Z)

All copyrighted and PD files must be deleted.

Out of the 74 categories,

Copyright and PD files without the owner's permission may be uploaded countless times.

End users should be prevented from uploading it.

Weki Media has copyrighted and strongly denied PDs.

If there's no way to solve this problem, Weki Media's public use will be damaged.

Unless this is resolved, damage can be repeated. 16:39, 2 December 2021 (UTC)[reply]

This user has left the same message on several discussion boards. I have closed down the duplicated discussions and only this one remains. Feel free to continue the discussion here. From Hill To Shore (talk) 17:06, 2 December 2021 (UTC)[reply]
If someone wants to dig through there, there looks like there's a few problematic images, but mostly it's free icons and interface shots of free software.--Prosfilaes (talk) 17:37, 3 December 2021 (UTC)[reply]

Category autocomplete is now case sensitive?[edit]

Hello, in the last few days I noticed that Category autocomplete has become case sensitive for a number of subjects (for instance - "Fishing boats of Portugal", but many others). I noticed this at home, and now in a different computer at the University, so it's not something from my system. Anyone else noticing this, too? What may have caused this (unwanted) change? -- Darwin Ahoy! 17:17, 2 December 2021 (UTC)[reply]

I've noticed the same thing. Cryptic-waveform (talk) 19:12, 2 December 2021 (UTC)[reply]
I have also. It could lead to starting unnecessary categories perhaps. Krok6kola (talk) 19:17, 2 December 2021 (UTC)[reply]
I'm guessing that this is due to a change in Cat-a-lot. I've added a comment here. Cryptic-waveform (talk) 19:35, 2 December 2021 (UTC)[reply]

Hi, using HotCat for a while already, has something changed recently? There are no longer all auto-suggestions for case-sensitive input - for example when I go by "Openstreetmap maps of fran...", there is no suggestion to continue with "...France", but just "...Frankfurt". I have to manually click and correct each letter that need to be upper case in order for the suggestion going with France, in that case "OpenStreetMap maps of France". This has become quite a hassle, because I now have to second-guess categories a lot more often. What do I need to change in my preferences; or is this something that Programmers need to fix? --Enyavar (talk) 12:48, 3 December 2021 (UTC)[reply]

December 03[edit]

Privacy violation?[edit]

Someone uploaded a newer version of an image and want it to be renamed. It looks like they want to hide privacy violation, but this is not the way to do that. But is it copyright violation, or just someone who doesn't wanna be on Commons with a picture? Can someone (an admin or?) take a look at that, or look with me? I'm not sure. See: File:Alice_Pasche.jpg. Thanks! - Richardkiwi (talk) (talk) 11:17, 3 December 2021 (UTC) PS it's a cross-wiki upload from[reply]

✓ Done Deleted. Yann (talk) 12:38, 3 December 2021 (UTC)[reply]
Thanks a lot! - Richardkiwi (talk) (talk) 14:34, 3 December 2021 (UTC)[reply]
You claim this is not the way to do that. Why? I think this is exactly that way to do that. Brianjd (talk) 05:55, 4 December 2021 (UTC)[reply]
Pinging @Richardkiwi. Brianjd (talk) 05:55, 4 December 2021 (UTC)[reply]
I see now that the file was overwritten with "junk"; in that case, you are right: this is not the way to do that. Brianjd (talk) 05:57, 4 December 2021 (UTC)[reply]
This was already 'done', so why are you meddling? There was no need to ping me afterwards or to 'suggest' something on my talk page. - Richardkiwi (talk) (talk) 12:15, 4 December 2021 (UTC)[reply]
@Richardkiwi I didn't know that {{Done}} meant that we weren't allowed to continue the discussion. I don't see it in the documentation for that template. Perhaps you would like to add it? Brianjd (talk) 12:22, 4 December 2021 (UTC)[reply]

Global ban for 1Goldberg2[edit]

Per the Global bans policy, I’m informing the project of this request for comment: RfC/Global ban for 1Goldberg2. – Mrakia 12:07, 3 December 2021 (UTC)[reply]

December 04[edit]