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 ↓
🌐 Village pumps for other languages
COMMONS DISCUSSION PAGES (index)
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:

 

Start a new discussion

People of Ngadisan (Java, Indonesia) are filling their cans at the village pump. The old well is defunct and replaced by a water tap. [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 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]

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

Magic Wand Icon 229981 Color Flipped.svg

Hello!

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.

Agenda

  • 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

Format

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 [email protected].

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]
That explains why none of my messages answered! --RAN (talk) 06:06, 6 December 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]

  • How are these images different from the >10,000 other images we have on the same subject? And why are you giving these images the Streisand Effect by telling everyone they are too naughty for us to host? --RAN (talk) 06:10, 6 December 2021 (UTC)[reply]
  • The discussion was closed as delete based in part on COM:DIGNITY. It seems like we resolved the issue. If there are other images like that, list them for deletion. If you want to chance the policy, then suggest a change at Commons talk:Photographs of identifiable people. -- Ricky81682 (talk) 07:55, 6 December 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 https://www.salarjungmuseum.in/European-Paintings.html
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]
Three out of four have been found and kept. Only one left to find. Multichill (talk) 17:08, 5 December 2021 (UTC)[reply]
The one which is left is likely modern.--Ymblanter (talk) 17:58, 5 December 2021 (UTC)[reply]

Unexplained[edit]

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 https://commons.wikimedia.org/w/index.php?title=Special:UploadWizard&campaign=wsc-it, 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]

The Wikimedia Sound Logo project

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:

https://meta.wikimedia.org/wiki/Communications/Sound_Logo

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. 217.117.125.83 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 [1] (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 [2]. 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]

i tried googling "railway signal five light". it does appear that there are real railway signal machines that look like these five light combos, but it's kinda weird that ten of these are put together? and facing no rails? and all switched on?
my wild guess is they're probably being tested?
maybe you could ask the station operator's social media https://www.instagram.com/renfe/ https://twitter.com/Renfe ? RZuo (talk) 23:59, 4 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.

Here

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. 125.181.255.254 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 fr.wiki[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]

Upload form Url[edit]

Hello all, is there any way to mass Upload Bengali pronunciations form here? —MdsShakil (talk) 16:03, 4 December 2021 (UTC)[reply]

@MdsShakil: Not while they have a CC BY-NC-SA licence. Non-commercial licence restrictions are not allowed on Wikimedia Commons. --bjh21 (talk) 17:07, 4 December 2021 (UTC)[reply]
@Bjh21 According to Ticket:2018060410003007, Licensing is not a problem. Copyright holder agree with following license as mentioned here. —MdsShakil (talk) 17:17, 4 December 2021 (UTC)[reply]

File:Mozart Sonate (manuscript).djvu[edit]

Hi, This is actually different that File:Manuscript of Violin Sonata No. 27 in G major, K. 379.pdf. I can't find the source, and I am not even sure what it is. Any idea? Yann (talk) 17:12, 4 December 2021 (UTC)[reply]

Copyright of photos of product wrappers[edit]

New user here. Suppose I buy a cookie at a store and then decide to take a photo of the cookie wrapper so that I can then upload the image. Would it be correct to mark the image as my own work?

I'm asking this because I'm planning to take photos of products whose wrapper contain the octagonal labels (e.g. "High in sugar", "High in fats", etc.) and upload them. I've already upload one photo, but before I start taking more photos, I wanted to make sure that they don't go against the guidelines.

Rdrg109 (talk) 18:18, 4 December 2021 (UTC)[reply]

  • @Rdrg109: Not OK. That is definitely a photo of a copyrighted work (the package is easily over the threshold of originality for copyright). - Jmabel ! talk 20:10, 4 December 2021 (UTC)[reply]
    As a new user, I can't state whether this is sarcasm or not. Please let me know either way. Rdrg109 (talk) 20:27, 4 December 2021 (UTC)[reply]
    I can see that the image was deleted, so this is not sarcasm. I will consider this from now on then. Note that you can find similar images in this category Rdrg109 (talk) 20:33, 4 December 2021 (UTC)[reply]
    Copyright and determining where the threshold of originality is are complicated concepts not easily navigated, and unfortunately oftennot evenly judged and enforced either. However, I would guess (since I can't see the image you uploaded) that in the images you linked, the difference is that they focus on the warning labels, and what is visible of the packaging is very generic and non-artistic. Beeblebrox (talk) 20:42, 4 December 2021 (UTC)[reply]
    How could I have taken the photo so that it is not over the threshold of originality for copyright? Note that you can find similar images in this category and the following are similar to the one that I uploaded (link link link link link link) Would they also be deleted? Rdrg109 (talk) 20:43, 4 December 2021 (UTC)[reply]

December 05[edit]

New user script: Warn you before opening large files[edit]

Hi, everybody! I have just created a new user script that gives you a warning if you're about to open a very large file from a file page. The default setting in the script is to give you a warning (a popup box asking you if you really want to open the file) if the width or height is larger than 10,000 pixels, or if the file is larger than 100 MB, but these are both configurable per user (see instructions on the script page). If you want to try it out, add the following line to your common.js: 

mw.loader.load( "https://commons.wikimedia.org/w/index.php?title=User:Jon_Harald_Søby/warnOnLargeFile.js&action=raw&ctype=text/javascript" );

The script also works for old versions of files in the file history table on file pages. Hope it will come in handy! Jon Harald Søby (talk) 01:53, 5 December 2021 (UTC)[reply]

Hiddencat or not hiddencat?[edit]

@Achim55, 4nn1l2, Verdy p, and Auntof6: and others is it certain that Category:Images from the Estonian Museum of Natural History geological collection is an administrative category and hence should be provided with hiddencat-tag?--Estopedist1 (talk) 07:54, 5 December 2021 (UTC)[reply]

This is clearly not an administrative category and should not be hidden! Brianjd (talk) 08:03, 5 December 2021 (UTC)[reply]
See the policy at Commons:HIDDENCAT, which mentions that many non-topical categories are hidden, but doesn't say what categories should be hidden.
This category seems non-topical and administrative to me. Spot-checking some similar categories, I see several that are hidden and one that's not. But in the absence of any guidelines/policies of what categories should be hidden, I'd say it's up to individual editors. Not ideal, I know. -- Auntof6 (talk) 08:58, 5 December 2021 (UTC)[reply]
@Auntof6 I don't see how this is any more administrative than, say, the subcategories of Maps by source. But perhaps I am simply demonstrating your point, that this situation is not ideal.
Also see Commons:Village pump/Archive/2021/11#Categorization question, which points out another inconsistency and suggests that this is a larger problem. There are also countless other discussions about hidden categories. Brianjd (talk) 09:07, 5 December 2021 (UTC)[reply]
I agree with Brianjd and disagree with Aunt6 here. This is a category by source, and there's no need to hide it. Hiding categories are those needed for maintenance purpose, and that do not provide metadata classification. But the indentification of sources is an important goal of Wikimedia, and it should not be hidden (even if these sources imply some possible maintenance to assert their legal right for imports).
Things would be different if these sources are jsut from individual users (private categories created by them for their own purpose, even if I think that these categories should not even exist, unless that user has a known, verifiable and asserted identify with public interest, e.g. from known artists, that decide to make their creations opensourced or in the public domain, in that case we'll need a proof from them and an assertion securely checked: in that case knowing these sources should not be hidden because we'll need that to preserve neutrality and correctly tagged contents that may be oriented so that reusers will know who has an interest, posibly commercial, to publish that content; but most users in Commons create opensourced contents or uploads photos from the observable public space and we can still track them by the fact that they are the uploader, without needing any categorzation; but some users upload a lot of things and want to organize their work and present it by subcategories, or to track their current work progress, and possibly add their own maintenance categories in their TODO lists, and in my opinion they should better just create subpages in their users pages to collect links to these contents, and otherwise categorize them in normal categories for general topics).
For now this category for contents uploaded from a public museum are properly tagged and subcategorized as a subcollection for that museum, and this does not need to be hidden at all; it is clearly not "administrative" and clearly not for maintenance purpose, and it has excellent value for metadata purposes and labelling, just like we have categories for images in the public domain coming from US agencies (such as the CIA) which are not neutral when they are built as a large colelction supposed to cover a whole domain of knowledge and present it according to their view (such collection may not be really exhaustive to cover these domains, even if these sources are considered "reliable" only because they are wellknown and easily verifiable as their sources, rather than for the content itself which may be tweaked and politically oriented, for example the presentation of borders and international claims as they are recognizd by the US, but not necessarily every country in the world)! verdy_p (talk) 10:17, 5 December 2021 (UTC)[reply]
Well, on the other hand, a category that currently contains 6000+ files is rather useless for people searching for images, the original purpose of categories. --Túrelio (talk) 10:21, 5 December 2021 (UTC)[reply]
This is also the case for categories created for various US or UN agencies... This does not mean that categorizing content there is enough! We need other categorization scheme by topic (subjects, epochs, artistic styles, colors, materials...). The same is true for categories related to public libraries. May be that category is now overpopulated and could be improved by splitting it further in subcollections. verdy_p (talk) 10:26, 5 December 2021 (UTC)[reply]
@Túrelio Not necessarily. Having this category displayed in the categories lists on individual files might be useful. Some people can apparently scan long lists of images quickly; this might be useful for them. But most importantly, there are tools that can combine multiple categories and other criteria, such as FastCCI and PetScan, and categories like this could be very useful with such tools.
If you still want to divide this category into subcategories, go ahead. Creating this category was obviously the first step towards achieving that.
So however you look at it, this is a good category to have. Brianjd (talk) 10:33, 5 December 2021 (UTC)[reply]
I agree, that this is clearly not an administrative category. Not to mention, that by marking this hidden nearly 1400 images got first marked as uncategorized and were then categorized under "Estonian Museum of Natural History" which is plain stupid. Yes, it would not be enough to mark images only into that geological collection category, but that [i.e the fact that this category contains a lot of images] does not make it an administrative category. That should be so obvious, that I don't see what is there to even ask about it or to make that kind of edit in the first place. Kruusamägi (talk) 14:47, 5 December 2021 (UTC)[reply]
Category:Images from the Estonian Museum of Natural History geological collection is a tracker category added by {{EMNH geo}} and according to Commons:Categories source categories are hidden. This has been standing practice on Commons for many years.
Images should be categorized by topic too and not only be in this category. You might find Commons:Guide to batch uploading & Commons:Guide to content partnerships useful. Multichill (talk) 16:30, 5 December 2021 (UTC)[reply]
  1. Clearly just placing something in this category would never be sufficient categorization.
  2. @Multichill: So are you saying that if someone takes an image of something in that collection at that museum themself, they should not add this category? - Jmabel ! talk
Exactly, source categories are to track who took or contributed a file. So for example Category:Images from the Rijksmuseum should only contain image that are from the Rijksmuseum (https://www.rijksmuseum.nl/en/rijksstudio) and not photos by people who visited the Rijksmuseum. Every file, regardless of it's source, should also have one or more topic categories like Category:Paintings in the Rijksmuseum Amsterdam or Category:Models of ships in the Rijksmuseum Amsterdam.
Generally source categories are used for tracking and not split up and diffused into subcategories like normal topic categories because that would make it harder to track these files. Tools like https://glamtools.toolforge.org/baglama2/ work on these (flat) tracker categories. Multichill (talk) 20:52, 5 December 2021 (UTC)[reply]

December 06[edit]

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&oldid=612168202"