Shortcut: COM:VP

#	💭 Title	💬	👥	🙋 Last editor	🕒 (UTC)
1	Problem with Upload	7	4	Sannita (WMF)	2024-06-10 12:11
2	Category:Film characters by actors	14	7	Jmabel	2024-06-09 23:56
3	Category:Men of the <country> by name, where "the" isn't needed	7	5	Jarekt	2024-06-10 13:06
4	I'm unable to use the image I just uploaded.	0	0
5	Help with cropping borders from images	17	6	LPfi	2024-06-09 06:58
6	Announcing the first Universal Code of Conduct Coordinating Committee	5	4	Boud	2024-06-11 20:15
7	EK 318 flight Dubai Tokyo 11 may 2024	20	6	Smiley.toerist	2024-06-10 08:19
8	Flickr & file credit	7	3	Jmabel	2024-06-10 17:50
9	List of living people & privacy	12	7	LPfi	2024-06-09 07:16
10	Special:UncategorizedCategories	4	2	Jmabel	2024-06-15 14:56
11	Any procedures for seeking and archiving explicit consent when subject is identifiable?	8	6	LPfi	2024-06-09 08:35
12	Placement of recurring terms in sets of subcategories	2	2	Prototyperspective	2024-06-09 15:35
13	RFC: Automatic categorisation both bane and gain; work needed to identify source of categorisation	29	10	JopkeB	2024-06-14 07:42
14	Japanese categories	4	3	Smiley.toerist	2024-06-15 22:35
15	Can I use this picture	3	3	Jmabel	2024-06-11 03:46
16	Category:Flags of fictional countries	10	5	Trade	2024-06-15 14:00
17	Notification of DMCA takedown demand — Autobiography of Banbhatta	1	1	JSutherland (WMF)	2024-06-10 23:03
18	Naming of concert photography categories	4	4	RZuo	2024-06-12 07:20
19	The final text of the Wikimedia Movement Charter is now on Meta	2	2	DarwIn	2024-06-13 16:06
20	New designs for logo detection tool	8	6	JWilz12345	2024-06-15 21:12
21	Renaming the Community Wishlist Survey: Vote for your preferred name	2	2	Enhancing999	2024-06-11 19:01
22	Is the June 2024 Ukraine peace summit logo copyright-free?	6	2	Jmabel	2024-06-11 23:18
23	Mechanism to request an image/map made	2	2	Alexanderkowal	2024-06-12 12:22
24	Weibo Watermark- Advertising?	2	2	Jmabel	2024-06-11 22:39
25	Cat for all foreign leaders visiting a specific country？	3	3	Enhancing999	2024-06-12 19:14
26	underscores in file names	4	4	Bawolff	2024-06-12 19:12
27	سرآسونٱ	1	1	Jarekt	2024-06-13 01:08
28	File:Dr. Yuval Karniel - Sammy Ofer School of Communications - Reichman University.jpg	8	6	Pi.1415926535	2024-06-13 19:45
29	Low server performance?	7	3	Jeff G.	2024-06-14 03:19
30	Have I got this right now	11	7	Broichmore	2024-06-14 22:18
31	File:לירן כוג'הינוף - עותק.jpg	6	3	Jmabel	2024-06-14 17:12
32	COM:Exif	2	2	Ruslik0	2024-06-14 20:05
33	7000x Georgia, the country	5	4	Enhancing999	2024-06-15 10:03
34	Uploading while editing wikipedias: beneficial or problematic?	26	9	Billinghurst	2024-06-16 03:32
35	Ideas or help related to the use of GFDL wiki-wide	2	2	TheDJ	2024-06-15 08:18
36	Mirrored image	2	2	Jeff G.	2024-06-15 14:26

Legend
In the last hour
In the last day
In the last week
In the last month
More than one month
Manual settings
When exceptions occur, please check the setting first.

Centralized discussion See also: Village pump/Proposals   ■ Archive How do we organize categories by date (14 May 2024) Proposal to prohibit political restriction templates (5 February 2024) Should PD-CQ Roll Call be used for recent images? (5 January 2024) Technical needs survey (17 December 2023) When does PDART apply to textile works? (15 November 2023) Does this image contain "love hearts"? (17 August 2023) Overhaul of categories by period (5 December 2022) Version of Saudi flag to use (11 July 2022) Concern regarding revocability of KOGL licenses (22 December 2021) Should deleting content from your own talk page be forbidden? (11 November 2021) Revise the COM:FOP Sweden section (1 February 2021) Change technical name of LRs to license-reviewer from image-reviewer(2 November 2023) Template: View   ■ Discuss    ■    ■ Watch

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

There is a problem with Special:Upload. Once you have completed the form and submit for uploading, if there is a problem with the selected file name it chooses a new valid name and gives you a chance to proceed. It used to have buttons to change the name or use the selected name. But the problem is it looses all of the description, licencing & categories that has been entered, just offering a blank form with a basic description template. Keith D (talk) 21:44, 22 May 2024 (UTC)[reply]

@Keith D: I'm not sure I follow that. Could you describe the old and new sequence, indicating where they differ? Or maybe someone can understand this as written and give you an answer. - Jmabel ! talk 17:32, 23 May 2024 (UTC)[reply]

It works for me, the form does not reset. Ymblanter (talk) 18:53, 4 June 2024 (UTC)[reply]

@Jmabel: Sorry for late response, I have been away without internet connection. Using Special:Upload to upload a file from Geograph project using the "directly upload this image to Wikimedia Commons" creates a completed upload file form. You can change this information and add appropriate categories before hitting the "Upload file" button. If the Destination filename contains a character that Commons does not allow, such as a colon, that is when the problem occurs when you try to submit the file upload. The old form would give you an error indicating that he file name was not acceptable and changed it to a valid file name. It then gave you 3 buttons, to accept the change, to modify it or exit the update. You could then proceed with the upload. Now the changed process gives you a button to refresh the screen to see if the upload has worked (this occurs for all uploads now). Once you hit button to see what it has done you get the message the file name is invalid and it revises it to a valid one. In this process it empties the Summary box detail and replaces it with a blank Information template (no fields completed) and the categories added are removed. Thus you have to refill in this information before you can resubmit the suggested modified file name. I think that extra refresh screen button stage that has been introduced is the problem. Hope this is clearer. Keith D (talk) 19:20, 4 June 2024 (UTC)[reply]

@Sannita (WMF): is this your realm? If not, do you know whose it is? - Jmabel ! talk 05:14, 5 June 2024 (UTC)[reply]

@Jmabel Not the focus of my team, but I can ask around. Can't promise anything. Maybe I can turn it into a Phab ticket and ping someone. Sannita (WMF) (talk) 11:40, 5 June 2024 (UTC)[reply]

@Keith D I opened phab:T367046 for your problem. I couldn't find anyone who is working on Special:Upload for the moment, but I'll keep trying. Please subscribe to the task on Phabricator to see if there are news. Sannita (WMF) (talk) 12:11, 10 June 2024 (UTC)[reply]

Most of these categories contain no media of their own, but subcategories of characters (that are often played by multiple actors), and the structure is often circular in nature (e.g. the category "Whoopi Goldberg" has the subcategory "Whoopi Goldberg characters", which has the subcategory "Shenzi", which has the subcategory "Whoopi Goldberg"). Most if not all of these were made by the same IP user who created a huge amount of category spam in Category:Space Jam, Category:Mickey Mouse and a bunch of others.

I don't think this category tree structure is inherently invalid, but I feel it's mis-applied and excessive in most of these cases. I'd like to hear more people's thoughts on this before I take this to CfD though. ReneeWrites (talk) 19:19, 28 May 2024 (UTC)[reply]

The whole thing seems rather ambiguous and pointless. Like the parent is called "Film characters" but then the subcategories aren't even characters. Or maybe they are. Is a category like that suppose to be for "characters of Chris Rock" or "Characters played by Chris Rock"? It's not really clear. Then on top of it a lot of the sub-categories only contain one child category but no files, which I'm not really a fan of. --Adamant1 (talk) 19:49, 28 May 2024 (UTC)[reply]

I think this category structure is invalid, and these categories should be deleted. The purpose of categories on Commons is fundamentally to categorize media files. These categories don't organize media; instead, they attempt to represent abstract relationships between subjects. But that's what we have Wikidata for! We don't need to create a clumsy imitation of it on this site.

The same probably goes for the following categories, at a minimum:

• Category:Actors by role - the inverse relationship of "film characters by actors"
• Category:Films by actor - same concept, organized by films instead of characters
• Category:Films by shooting location - encoding minor facts about films into categories

Omphalographer (talk) 17:58, 29 May 2024 (UTC)[reply]

Most of the categories in Category:Actors by role were made by the same guy who filled Category:Film characters by actors and made the over 500 categories for Space Jam, Mickey Mouse, Scooby Doo etc. I took to CfD earlier. ReneeWrites (talk) 10:19, 30 May 2024 (UTC)[reply]

CfD plz Trade (talk) 15:59, 30 May 2024 (UTC)[reply]

@Trade: Created a CfD for Film characters by actors and Actors by role. ReneeWrites (talk) 19:29, 30 May 2024 (UTC)[reply]

Commons is not the place for this. Al Capone is not defined by Alec Baldwin and neither is Alec Baldwin defined by Al Capone. All of these categories should be deleted. The only place this data should be presented is in Wikipedia. Wikidata, might hold the names of movies and their casts, however that again is held in Wikipedia. We are not a repository of facts; we hold files, last time I looked. Only recently we had to go through this nonsense with film locations. Broichmore (talk) 12:20, 4 June 2024 (UTC)[reply]

@Broichmore: Could you link me to the discussion about film locations? Was there a consensus? ReneeWrites (talk) 20:31, 4 June 2024 (UTC)[reply]

Commons:Categories for discussion/2021/03/Category:Film locations by film (and the discussion which led into that, Commons:Categories for discussion/2020/11/Category:Film locations of Sonic the Hedgehog). Omphalographer (talk) 21:58, 4 June 2024 (UTC)[reply]

Thank you 🙂 ReneeWrites (talk) 22:05, 4 June 2024 (UTC)[reply]

Why is the category blue if consensus were to delete? Trade (talk) 02:42, 9 June 2024 (UTC)[reply]

@Trade: This is about a current discussion, not one that his been concluded. - Jmabel ! talk 15:27, 9 June 2024 (UTC)[reply]

Agree about the general problem, as mentioned above, the problem with Category:Films by actor from the United States (or Category:Films by actor) in general is similar.

The main question to solve is: where to place a picture of actor x playing the character y in the film z? In the three categories for each of these. Enhancing999 (talk) 17:27, 9 June 2024 (UTC)[reply]

Under the actor, the character (if we have such a category), and (if that character is not a subcat of the film) the film. If we have more than a handful of such images for the same actor in the same film, then we can make a subcat bringing the three together. - Jmabel ! talk 23:56, 9 June 2024 (UTC)[reply]

This was brought up here last year for category "Men of the France by name". There are now over 53,000 links to it -- not entries in it, but links to the category. There are also over 50,000 links to "Men of the Germany by name". I see similar ones for other countries. (You can find them under Special:WantedPages.) None of the categories actually exist. I gather that a module was changed to fix this problem, but the problem has apparently recurred. Can someone help? -- Auntof6 (talk) 14:24, 31 May 2024 (UTC)[reply]

It looks like the Special:WantedPages are cached and only updated twice a month. I assume the use of the category was due to a template error that has since been fixed. I would wait to do anything until the next update of wanted pages. I think I'm wrong with my previous comment. Please disregard. William Graham (talk) 19:18, 31 May 2024 (UTC)[reply]

This may be an issue with {{Wikidata Infobox}}. I would ask on the template talk page and see if the maintainers have any idea what is going on. I know that from previous go arounds on this, the template/Lua script checks for instances of "the" country categories at some point in the execution. William Graham (talk) 19:23, 31 May 2024 (UTC)[reply]

Possibly the check for existence adds it to the "wanted" list. Enhancing999 (talk) 19:23, 31 May 2024 (UTC)[reply]

William Graham You are correct {{Wikidata Infobox}} and Module:Wikidata_Infobox in lines 1283-1294 does exactly that. It checks for existence of category with and without "the", and the first check is for the options with "the". User:Mike Peel and User:LennardHofmann maintain that code. Mike and Lennard I suspect that some countries always use "the" and some don't so you should be able to create a lookup table of maybe all the countries that use "the" and at least have a good guess which one of 2 options to try first. If you want I can write a patch to fix this. --Jarekt (talk) 01:52, 2 June 2024 (UTC)[reply]

 Done @Auntof6, William Graham, Enhancing999, and Jarekt: Ahh, it's this 17-year-old MediaWiki bug again – you love to see it. I replaced all "#ifexists" checks with a lookup table, see Special:Diff/882129679. --LennardHofmann (talk) 13:23, 8 June 2024 (UTC)[reply]

LennardHofmann, thank you for fixing this. --Jarekt (talk) 13:06, 10 June 2024 (UTC)[reply]

Hi I don't seem to be able to use the file https://commons.wikimedia.org/wiki/File:M_F_Gervais_Holy_Roman_Empire.pdf It show up in Commons but in Wikipedia I'm not able to use it. Why? It happened for my last file and someone 'did' something... I don't know what was done but it worked. What should I do to fix it? — Preceding unsigned comment added by M F Gervais (talk • contribs) 18:45, 31 May 2024 (UTC)[reply]

@M F Gervais: It is there and it functional however due to how big and unwieldy it is as a pdf it takes a while to render, especially whern it has to develop the image cache first:

Now because PDFs are typically multipage document it can need extra formatting if you are trying to do it through standard wiki formatting. mw:help:images. PDFs should not be used if you want to display an image, please upload an image file per Com:File types — Preceding unsigned comment added by Billinghurst (talk • contribs) 07:59, 1 June 2024‎ (UTC)[reply]

Hi. I was wondering if people could help me crop the borders from images in Category:Images from the German Federal Archive with borders. It currently contains 23,469 images that need cropping which isn't great, but every little bit helps. Thanks. --Adamant1 (talk) 05:22, 2 June 2024 (UTC)[reply]

23,317 images now 🙂 ReneeWrites (talk) 19:20, 2 June 2024 (UTC)[reply]

Why, I dont see any images in urgent need of cropping, please give some examples Broichmore (talk) 19:52, 2 June 2024 (UTC)[reply]

@Broichmore: it looks like a lot of these have a watermark in a margin. - Jmabel ! talk 21:34, 2 June 2024 (UTC)[reply]

They have catalog numbers, which say something about the DDR. Their discreet enough, not to worry about. Broichmore (talk) 10:50, 3 June 2024 (UTC)[reply]

For those who don’t know, Commons:CropTool is handy for this. —Justin (koavf)❤T☮C☺M☯ 21:41, 2 June 2024 (UTC)[reply]

When it works, which it mostly doesn't lately. - Jmabel ! talk 22:09, 2 June 2024 (UTC)[reply]

I just did several with no issues. I have rarely had problems with that tool. —Justin (koavf)❤T☮C☺M☯ 22:32, 2 June 2024 (UTC)[reply]

Yesterday I overwrote an image, when I went to crop out details from the new image, croptool wanted to goto the original image to do the croppng. Had to resort to GIMP to do the job. It wasn't a cache problem. Broichmore (talk) 10:54, 3 June 2024 (UTC)[reply]

I started using CropTool yesterday to assist with this task, so far it's worked like a charm. ReneeWrites (talk) 16:44, 3 June 2024 (UTC)[reply]

Good. Doing some back-of-the-envelope math, someone can plausibly do three of these a minute, so with 23,000 images, that means 128 person-hours of work, which is a lot for one person, but reasonable for a small group. —Justin (koavf)❤T☮C☺M☯ 20:54, 3 June 2024 (UTC)[reply]

Just to say, the museum source has not cropped them, why would they not? There seems to be some kind of mania, here, in cropping out borders to satisfy OCD urges. Margins prove the extent of images, they confirm that images are indeed complete. Any source museum would consider this vanadalism. I have to say that certain museums employ prestigous decals on their images, claiming source, the Imperial War Museum, The British Library, the Bundesarchive in this case. Cropping out these details, deny them the opportunity of advertising, which is cheeky when you consider they curate these images for us for free. These Bundesarchiv decals that are being cropped out deny 'end users' easy attribution of where these images come from. Wikipedia in particular is bad for not only referencing the source museum, but also even the artist. Furthermore, in the new world of AI, these decals go some way to prove authenticity. At this point their discreet enough, not to worry about. This is not a good use of our resources, and is wrong. Broichmore (talk) 08:24, 4 June 2024 (UTC)[reply]

@Broichmore: I don't necessarily disagree. If I had my way I'd probably just remove the crop requests, but I didn't add them to begin with and I try to respect what other users want. It would at least be less work to just not crop the images to begin with though. --Adamant1 (talk) 09:35, 4 June 2024 (UTC)[reply]

Indeed, the thing is that every so often editors discover the crop tool and see it as an easy pastime. When in fact it's a tool that should be rarely used, and with great caution. The average original uploader is more than capable of cropping their images prior to uploading, their wishes should be respected.

Even in these images, the Bundesarchiv logo, tell us so much. Date, German origin, the importance put on collecting the image by the German government, and that they consider it being worthy of preservation, & etc. Broichmore (talk) 09:53, 4 June 2024 (UTC)[reply]

This misunderstands how Wikipedia/Commons attributes images. The sources and authors are listed on the image's descriptions pages, not in the text on Wikipedia itself (this also to discourage using Wikipedia as a tool for self-promotion). With regards to this collection specifically, the information listed in the image is also listed on the page (the bild ID (and a link to the ID on the archive), the year it was taken, the name of the photographer, if one is known, the archive itself). This is where that information is supposed to be; there is no need to have it be visible on the image too. This kind of visible watermarking is discouraged. Invisible watermarking on the other hand is encouraged because it doesn't interfere with the contents of the images themselves. Every single one of the images in this collection has invisible watermarking too (the EXIF data if you scroll to the bottom), which contains the same information that's visible in the margins, and is wholly unaffected by the crop tool. ReneeWrites (talk) 13:31, 4 June 2024 (UTC)[reply]

@ReneeWrites: I don't misunderstand anything. While attribution is optional on Wikipedia; not every source is notable. However, many, and most are!

Discerning casual readers (who are, who Wikipedia aims itself) want to know the source of artwork or notable photographs.

I am yet to see an encyclopaedia, or source book which does not attribute at the front end. Children's books don’t attribute. Hiding attribution as you describe, is a successful way of withholding information from Wikipedia’s readership. The majority of which, are in computing terms illiterate.

As an incentive, the secret to successful Wikipedia writing is creating ''links'' to other articles on the project. There is an ongoing opportunity to link, to articles, about ''said'' notable artists and photographers. Those players, in turn, are often part of the stories themselves.

You couldn’t be more wrong, attribution and referencing is the very woof and warp of an encyclopaedia. Broichmore (talk) 19:19, 8 June 2024 (UTC)[reply]

If you want the image info to be visible directly in Wikipedia articles, then try to create a policy on Wikipedia recommending attribution in the caption. The info in the image border isn't visible in the thumbnails actually shown. You need to click at the image anyway to be able to read that information, and it is much more prominent in the actual file description than in the tiny text on the border. Now, clicking may get you to the image viewer instead of the image description page, but even then, clicking "more info" (and searching for that link) isn't unreasonable if you want to get to that info. (Many books attribute images in a separate list instead of "at the front line"; if you want the info, you have to look for it.) –LPfi (talk) 06:58, 9 June 2024 (UTC)[reply]

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Hello,

The scrutineers have finished reviewing the vote results. We are following up with the results of the first Universal Code of Conduct Coordinating Committee (U4C) election.

We are pleased to announce the following individuals as regional members of the U4C, who will fulfill a two-year term:

• North America (USA and Canada)
  • –
• Northern and Western Europe
  • Ghilt
• Latin America and Caribbean
  • –
• Central and East Europe (CEE)
  • —
• Sub-Saharan Africa
  • –
• Middle East and North Africa
  • Ibrahim.ID
• East, South East Asia and Pacific (ESEAP)
  • 0xDeadbeef
• South Asia
  • –

The following individuals are elected to be community-at-large members of the U4C, fulfilling a one-year term:

• Barkeep49
• Superpes15
• Civvì
• Luke081515
• –
• –
• –
• –

Thank you again to everyone who participated in this process and much appreciation to the candidates for your leadership and dedication to the Wikimedia movement and community.

Over the next few weeks, the U4C will begin meeting and planning the 2024-25 year in supporting the implementation and review of the UCoC and Enforcement Guidelines. Follow their work on Meta-wiki.

On behalf of the UCoC project team,

RamzyM (WMF) 08:14, 3 June 2024 (UTC)[reply]

• I'm probably lacking some context here, but why the many (majority, actually) that are simply "–"? - Jmabel ! talk 14:56, 3 June 2024 (UTC)[reply]

  @Jmabel The m:U4C Charter requires that candidates get at least 60% support to be elected. Only 7 candidates were elected, so the U4C does not have a quorum to operate. AntiCompositeNumber (talk) 01:29, 9 June 2024 (UTC)[reply]

  • @AntiCompositeNumber: thank you. Very odd that the announcement above makes no mention of that. - Jmabel ! talk 01:55, 9 June 2024 (UTC)[reply]
    • @Jmabel and AntiCompositeNumber: Good points. @RamzyM (WMF): It does seem rather misleading to talk about U4C starting its work without mentioning that the U4C is sub-quorum and is limited to only carrying out actions that do not require votes. Boud (talk) 20:15, 11 June 2024 (UTC)[reply]

I was seated close to a window and have taken some pictures: The camera time is the time in Amsterdam, not the local time. The route is trough Pakistan and China. There where no delays.

• 
• 
• 
• 
• 
• 

Identifying the location would be usefull. Smiley.toerist (talk) 11:25, 3 June 2024 (UTC)[reply]

I've done this sort of thing a lot. I strongly recommend plunging into Google Maps looking for similar landforms. (BTW, for the future: much easier if you take a lot of pictures, even if you don't plan to use them all.) - Jmabel ! talk 14:59, 3 June 2024 (UTC)[reply]

Also useful is if you are listening in-flight to the pilots talk to Air Traffic Controllers, making a note of which Air Traffic Controllers' areas the pilots are told to switch to (the next area on the flight plan); for flights arriving here, that is typically "New York Approach". The frequencies are not necessary for this purpose. It will help if you can listen in English, as that appears to be the standard language of air traffic control worldwide.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:09, 3 June 2024 (UTC)[reply]

De official times are Dubai departure 02:40 am local time and arrival at Tokyo 17:35 pm local Japanese times. Camera time Amsterdam GMT + 1 (+ 1 summertime); Dubai GMT + 4; Japan GMT + 9. 7 hour difference between Japan and Amsterdam. China is GMT + 8). From what I remenber the plane avoided India went trough Pakistan and then took a more or less straight line trough China and South Korea passing trough large Chinese dessert areas. So the Himalayas would be at de western end by the Pakistan / Chinese border, but could also be inside China.Smiley.toerist (talk) 16:52, 3 June 2024 (UTC)[reply]

@Smiley.toerist: At least the city on last three images should be relatively easy to identify e.g. with Google Maps satellite mode; provided you know at least approximately what area and/or what country had been overflown at that timepoint, as otherwise this would be a search for the "needle in a haystack".

In general, it's quite tricky and common landforms are difficult to identify afterwards, likewise in flight because from my experience, GPS on your phone seldom works well in flight. --A.Savin 16:27, 3 June 2024 (UTC)[reply]

The solution to have and keep a GPS connection in fast moving vehicles with a smartphone is to activate a constant tracking before you start moving. For these photos case it might be the best solution to look at the Flightradar24 data for the flight and then matching the capture time. But that requires a paid account there. GPSLeo (talk) 16:43, 3 June 2024 (UTC)[reply]

The last picture must be in Japan, about 15 minutes before landing. With the long shadow of a western sun, this must be an east coast. Smiley.toerist (talk) 17:02, 3 June 2024 (UTC)[reply]

Bingo! The Kaimon Bridge by Kaimoncho.Smiley.toerist (talk) 17:11, 3 June 2024 (UTC)[reply]

(EK 318 flight Dubai Tokyo 11 may 2024 4) is close to JR station Izumi and (EK 318 flight Dubai Tokyo 11 may 2024 5) is close to Otsu port (found on GE). I have problems finding the correct location categories. Narita airport was approached from the north along the coast.Smiley.toerist (talk) 17:56, 3 June 2024 (UTC)[reply]

I have worked the 3 Japanese pictures. For one File:EK 318 flight Dubai Tokyo 11 may 2024 4.jpg, I set the location coordinates of the estmated viewpoint up in the air, but it maybe better to have the coordinates of the center of the image. In this case the river entry point in the ocean.Smiley.toerist (talk) 09:20, 4 June 2024 (UTC)[reply]

Use ADSB data...

1. Go to https://www.flightaware.com/live/flight/UAE318
2. Select flight from past flights (right now only goes back to 21 May, but free basic member can go back 3 months)
3. click track log to show time → latitude longitude

Glrx (talk) 17:37, 3 June 2024 (UTC)[reply]

I managed to find the location of the desert village in Xinjiang

Camera location	38° 39′ 53.74″ N, 87° 21′ 19.6″ E	View all coordinates using: OpenStreetMap

, by doing some time and distance calculations and finding out that the village must be about 3.258 km from Dubai. The scharp dark green fields contrast with the more dessert like image from Google Earth. The most dificult to lokalise images must be the two mountain images where I wil probably be using ADSB data.Smiley.toerist (talk) 10:21, 4 June 2024 (UTC)[reply]

Calculating that the mountain views 71 minutes before the dessert village, places the mountains within Pakistan. (13,03 km by minute)Smiley.toerist (talk) 10:36, 4 June 2024 (UTC)[reply]

The ADSB data of past fligths indicate that the plane usualy crosses Chinese border halfway between the Afganistan border and the Indian border (line of control). Close to the line, a bit to the East is the K2 mountain. However it is complicated to find the rigth mountain.Smiley.toerist (talk) 19:59, 4 June 2024 (UTC)[reply]

ADSB for flight that took off Sunday 02:45:00 AM UTC+04

• https://www.flightaware.com/live/flight/UAE318/history/20240511/2250Z/OMDB/RJAA/tracklog

I have to use camera time as UTC+2. Otherwise, the last picture is taken after the plane lands.

Pictures

ADSB Location

Picture	EXIF Time 11 May 2024 UTC+2	UTC 11 May 2024	EDT UTC-4	Location	Heading
1	03:39	0139Z	21:39	36° 06′ 41.4″ N, 75° 16′ 14.16″ E  View all coordinates using: OpenStreetMap FlightAware estimated (10 mins since last fix)	→ 70°
2	03:40	0140Z	21:40	36° 06′ 41.4″ N, 75° 16′ 14.16″ E  View all coordinates using: OpenStreetMap FlightAware estimated (10 mins since last fix)	→ 70°
3	04:51	0251Z	22:51	38° 45′ 34.92″ N, 86° 14′ 08.52″ E  View all coordinates using: OpenStreetMap FlightAware estimated (80 mins since last fix)	→ 76°
			22:58:36 +7.5 min	38° 57′ 39.24″ N, 87° 20′ 20.4″ E  View all coordinates using: OpenStreetMap FlightAware estimated (90 mins since last fix)	→ 77°
4	10:12	0812Z	04:12	36° 14′ 53.88″ N, 140° 38′ 03.84″ E  View all coordinates using: OpenStreetMap	↘ 133°
5	10:12	0812Z	04:12	36° 14′ 53.88″ N, 140° 38′ 03.84″ E  View all coordinates using: OpenStreetMap	↘ 133°
6	10:17	0817Z	04:17	35° 56′ 35.88″ N, 140° 45′ 37.8″ E  View all coordinates using: OpenStreetMap	← 289°

Glrx (talk) 23:11, 4 June 2024 (UTC)[reply]

Thank you all!   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 23:58, 4 June 2024 (UTC)[reply]

Thanks for the info. The positions are estimations and imprecise. I was on a seat on the left side. By the landing (4, 5, 6) the plane was clearly flying over land and not over the sea. The details of picture 3 match with the GE satelite picture. As the plane was flying around 10 km heigth and the village has a low altitude of 1017 meter above sealevel the plane must have been someway south of that position.Smiley.toerist (talk) 09:36, 5 June 2024 (UTC)[reply]

For pictures 1 and 2 the sun was a morning sun from the east. Pic 2 is the same mountain taken a minute later.Smiley.toerist (talk) 09:45, 5 June 2024 (UTC)[reply]

First, a jetliner cruises at about 1000 kmph or 16 km per minute. An error of 5 minutes is 80 km.

I did not interpolate the position from the ADSB data; instead I just chose a close time. Interpolation would be better if we know the times are accurate.

The error for the village is large. To match the longitude, I had to advance the time by 7.5 minutes, but the ADSB plane position was still well north of where it should be. The issue is partly resolved by the position being estimated because there is no actual ADSB data during that part of the flight.

The ADSB data that is not estimated should be accurate. The numbers I used do put the plane over water when it should be over land. However, you can look at track as it approaches the airport and see that portions of that track do align with the pictures.

That error may just be a time offset. You might see how accurate your camera clock is right now. Alternatively, you could try to figure it out from a reasonable track position for a particular image. That's what I was trying to do with the 7.5-minute village offset until I realized the track didn't fit and noticed the ADSB data for that time was only an estimate.

The EXIF data also has a quantization error of 1 minute.

I expect the ADSB times to be derived from the GPS satellites.

Glrx (talk) 21:02, 5 June 2024 (UTC)[reply]

I have added coordinates to the landing images 5 and 6, on the visual estimation with identified landmarks 'Cape Otsu' (File:Cape Otsu Lighthouse (Kitaibaraki City).jpg) and 'Kaimon Bridge'.Smiley.toerist (talk) 08:19, 10 June 2024 (UTC)[reply]

Is it actually useful for structured data to mark my own file that I copied from my own Flickr account as authored by Flickr user Joe Mabel, as against Commons user Jmabel (both me)? - Jmabel ! talk 15:04, 3 June 2024 (UTC)[reply]

I would say so. Most Commons users upload their files here directly, not via Flickr. And most of the time when people upload files from Flickr with the Flickr2Commons plugin they are not the original author of those images, so it makes sense (and is imo useful) if that credit line is automatically attributed to the Flickr profile the images are from. For your own images you could always edit the credit line to your Commons profile if you prefer to be credited that way. ReneeWrites (talk) 20:27, 4 June 2024 (UTC)[reply]

@ReneeWrites: I did rewrite the credit in the wikitext. And then the bot goes through and writes the SDC as if I had not done so. - Jmabel ! talk 05:18, 5 June 2024 (UTC)[reply]

Disregard my previous comment, I misunderstood the problem. ReneeWrites (talk) 11:21, 5 June 2024 (UTC)[reply]

Here is a much more egregious example: File:Ford Model "T" car no. 2, winner of the 1909 trans-continental race from New York to Seattle.jpg. At all times, the Wikitext has accurately indicated that this is a photo by Frank H. Nowell, official photographer of the Alaska-Yukon-Pacific Exposition. Originally that was in the description rather than the author field, but I fixed that in 2010 and added a {{Creator}} template in 2016. FlickypediaBackfillrBot marked it today in SDC as being created by University of Washington Libraries Digital Collections because that is the immediate source. That strikes me as absolutely wrong.

@Alexwlchan: do you consider this correct behavior by your bot, and if so why? Otherwise, is there some hope of addressing this? - Jmabel ! talk 17:44, 5 June 2024 (UTC)[reply]

I agree that the SDC should point to the named photographer if known, and not the Flickr user.

I think the bot’s behaviour is fine.

• It didn't delete or replace the information in the Wikitext. It only added a creator (P170) SDC statement because there wasn’t one on this file before.
• If there's already a creator (P170) statement, the bot leaves it as-is. I could point you to literally thousands of examples where the bot has looked at a file, seen a P170 with more specific information, and left it as-is.
• If the file is edited to add a more specific statement, the bot will leave it as-is. I’ve done a manual edit to replace the Flickr user statement with one that points to Frank H. Nowell (Q26202833), and if/when the bot processes that file again, it won’t make any changes to P170.

Is this a widespread problem with the bot, or is this an unusual example? Alexwlchan (talk) 08:28, 10 June 2024 (UTC)[reply]

• • I'd say it's widespread. It is going to happen literally any time a user first uploads their own content to Flickr and than imports it to Commons, and literally any time a third party posts historical content to Flickr and someone imports that. - Jmabel ! talk 17:50, 10 June 2024 (UTC)[reply]

Hi,
I was wondering if there were any privacy issues with a list of people's names, like this one?
Thanks. --Kontributor 2K (talk) 10:27, 4 June 2024 (UTC)[reply]

Similar images available at Category:Name lists and Category:Lists of people (side note: should these be merged?) Dogfennydd (talk) 12:18, 4 June 2024 (UTC)[reply]

I mean that this a list of living people (1977), where you can see their religion and early school's name, hence my question

--Kontributor 2K (talk) 12:44, 4 June 2024 (UTC)[reply]

• Every school yearbook in the United States is online, either here, or Classmates or Ancestry. --RAN (talk) 18:25, 4 June 2024 (UTC)[reply]

This would be unbelievable to have in Germany :D --PantheraLeo1359531 😺 (talk) 18:32, 4 June 2024 (UTC)[reply]

Unfortunately Ancestry would guillotine the books to ease scanning then discard the originals. I used to buy them at book sales and see if it was on their list of needed copies, but stopped when I learned their policy. Having them online is absolutely awesome. --RAN (talk) 21:48, 5 June 2024 (UTC)[reply]

in germany you can find a list of full names and a group photo of students doing abitur in a certain year on the newspaper and its website. XD

that's unbelievable in many other countries. RZuo (talk) 05:41, 6 June 2024 (UTC)[reply]

• In France, it's illegal too to distribute private data without the prior consent of the concerned people. --Kontributor 2K (talk) 07:30, 5 June 2024 (UTC)[reply]
  • This is probably just my lack of understanding of French law but, @Kontributor 2K: given that this appears to have been a published document, how is this "private data"? - Jmabel ! talk 17:46, 5 June 2024 (UTC)[reply]
    • I don't think it's been published (like a book); it's just been printed.
      In general, this type of document is given to families at the end of the school year, or after the ceremony.
      It's not a public document. --Kontributor 2K (talk) 17:58, 5 June 2024 (UTC)[reply]
• Under international copyright law that does constitute being "made public", also lists of names are not copyrightable. To be eligible for a copyright a work must have unique creative elements. If you asked a dozen people to compile the list of names, each person would create an identical list. If you asked a dozen people to compile a list of the best music of all time, each list would be different and copyrightable, that is why the Time 100 list each year is copyrighted, or the Fortune 500 list. --RAN (talk) 21:44, 5 June 2024 (UTC)[reply]

  You mean the Berne convention? Anyway, is privacy law coordinated with copyright terminology? In Finland, we have a lot of material that is public (you will get it if you ask), but still publishing it in a newspaper or similar is illegal unless there is sufficient public interest or other specific reasons to. This includes tax records and court cases. –LPfi (talk) 07:16, 9 June 2024 (UTC)[reply]

Special:UncategorizedCategories is back over 1000 categories. If you can add appropriate parent categories to any of the many that have otherwise reasonable content, that would be very helpful. If you're not a admin, don't worry about the empty ones, one or another admin will eventually find those and delete them. - Jmabel ! talk 06:05, 5 June 2024 (UTC)[reply]

Now up to 1165 categories. I have the feeling almost no one is addressing this. I've done literally thousands, probably over 5000, and while I still try to do 50 or so per week, that is not enough to keep up. - Jmabel ! talk 17:53, 10 June 2024 (UTC)[reply]

@Jmabel: I did a few today and about once a month a small portion.

 Question Is it a good idea to have the numbers next to the categories, like in other pages? Then you can see at a glance which are empty and not bother about them (for none admins like me) or to be able to remove them in quick succession (for admins). JopkeB (talk) 07:50, 15 June 2024 (UTC)[reply]

Wouldn't that be nice? As it is, in case you haven't noticed, you can hover over the link and see whether there are files in the category. - Jmabel ! talk 14:56, 15 June 2024 (UTC)[reply]

I took the photograph shown and have had a clear and unequivocal discussion with Michael Winter, the subject, that I can upload that and similar images to Wikimedia under CC‑BY‑4.0. Michael also provided me with his email address on my request and I was intending to follow up with a proper "release form".

That event occurred in Berlin, Germany of course and German and European privacy law would prevail.

I have had a reasonable look around this site and could not find mention of any formalized processes like this. The notion of "asserted consent" is traversed. So I take it that Wikimedia does not wish to provide support for written agreements of this nature? I guess that position is understandable? Particularly given the large number of legal jurisdictions involved and also changing statutes and evolving case law.

So I suppose the best thing to do in this particular case is to undertake some email traffic with Michael and leave that exchange on my hard‑drive as a kind of insurance policy? Any assistance welcome. RobbieIanMorrison (talk) 17:54, 6 June 2024 (UTC)[reply]

Yes, the process is described at COM:VRT. GPSLeo (talk) 17:59, 6 June 2024 (UTC)[reply]

COM:VRT talks mainly about licensing by copyright-holders, but the same process could presumably be used to ticket for issues related to other rights. You might want to ask a question at Commons:Volunteer Response Team/Noticeboard to find out how they'd prefer to to handle this particular case. - Jmabel ! talk 18:05, 6 June 2024 (UTC)[reply]

Thanks GPSLeo and Jmabel. I did once use that process for another image in relation to consent. In that case, my associated email traffic was somehow stored out of public view and linked backed to the particular image. I also presume that my earlier assumption that the concept of release forms is not supported by Wikimedia due to the legal complexities present. Thanks both for your quick responses. RobbieIanMorrison (talk) 19:17, 6 June 2024 (UTC)[reply]

According to Commons:Photographs of identifiable people you could add {{Personality rights}} and {{Consent}} if you haven’t already. Bidgee (talk) 19:39, 6 June 2024 (UTC)[reply]

Maybe we could add a param to consent, so that people can reference a document id, link or VRT/OTRS id. That might be worthwhile! —TheDJ (talk • contribs) 19:51, 6 June 2024 (UTC)[reply]

For what it is worth, the accompanying image of the woman in yellow uses the following field "permission={{VRT info|1=2024050810008791}}" as part of the 'Information' template. RobbieIanMorrison (talk) 21:21, 7 June 2024 (UTC)[reply]

Only the VRT agents can see what info that ticket includes, so whether it is relevant to this discussion is unclear. But yes, that's the way to link to such correspondence. You could reference it in the permission field if you want reusers to know something about what privacy issues are covered. –LPfi (talk) 08:35, 9 June 2024 (UTC)[reply]

Are pre- or postmodifiers preferable in cases like those that are being discussed in Commons:Categories for discussion/2023/12/Category:Old women sitting? I.e. when the option is semantically appropriate and linguistically feasible, do we want e.g. sitting-related subcategories to be called "Sitting x, Sitting y, Sitting z" or "x sitting, y sitting, z sitting"? As per my post in the category discussion, I think the latter makes the most sense, but perhaps there is more information and/or user consensus to be found somewhere. Sinigh (talk) 14:07, 8 June 2024 (UTC)[reply]

Makes sense but "Old women" is also a recurring term so the optimal solution both this and items where the former term is a nonrecurring one would be to have redirects so that e.g. Old women sitting redirects to Sitting old women or the other way around. Would be good if there was a bot/script that did so / created redirect proposals one could quickly confirm or add to a list of likely inappropriate proposed redirects. (The same could maybe also be done for category names in languages other than English but that's another topic.) Prototyperspective (talk) 15:35, 9 June 2024 (UTC)[reply]

Hi. Having been involved in large amounts of tidying over the years we are starting to get to an administrative burden from automatic categorisation where it is going wrong, Our use of complex and layered templates that directly apply categories, eg. Template:Topic by country, or the inhalation of categories based on Template:Wikidata infobox, or through Modules is requiring more and more time and more and more complex knowledge to resolve this (mis)categorisation where it goes wrong, or where it causes issues outside of our criteria.

We need some better technical solutions. We need a direct and overt ability to know the source of the categorisation be it:

1. direct category in the page
2. template that has local data
3. template that is importing information from wikidata

Some of this sort of exists when one has Com:HotCat as a gadget, though the other two have no ready means to identify the source.

Categorisation is clearly something where automation is useful and it is not in itself the problem. When it is wrong, and needs a lot of work to resolve, then it moves from problem to big problem.

We also need a better means for getting resolution categorisation fixes of the points in #2 and #3. We need guidance to people to how they best address categorisation that has gone wrong and they don't know how to fix it. Some of that is that we need to review our documentation in the templates to ensure that they have guidance for the appropriate use of the template, and what it actually does, as well as the guidance on the appropriate use of the parameters. Template designers/creators need to be involved in that space as an expectation, and those that put them through major rewrites. If it is hard to use and hard to understand then the community needs to challenge both its design and its purpose.

If we don't do something the categorisation issues are going to continue to multiply, and the rules that we have in place will be ignored and we will just have mess. I know that I am partly just stating the problem, and not necessarily the solution, however, at this point I am looking for comments about where others think we are, and some general thoughts on how we can address this at a higher level before drilling down into all the solutions.  — billinghurst sDrewth 00:22, 9 June 2024 (UTC)[reply]

It's probably a side thing, but I have a serious problem with categories being forced on us through infoboxes. Like there's a ton of people who are recipients of minor, non-notable awards that automatically get sorted into categories for said awards and their various sub-awards when it's not really useful to have things categorized down to that small of a level. You can't really do anything about it on our end either. Regardless, we shouldn't have how we categorize things dictated by other projects period. We certainly don't name categories based on standards set by Wikipedia editors, or keep files that violate the guidelines simply because of how other projects do things. -Adamant1 (talk) 00:34, 9 June 2024 (UTC)[reply]

Wikidata Infoboxes provide given name, surname, and birth and death dates, and "living people", which should presumably be uncontroversial. [Similarly, some gender info so it can do "men by name" and "women by name" as well as "people by name". - Jmabel ! talk 01:53, 9 June 2024 (UTC)] I'm not at all sure they should do any other automatic addition of categories, though there may be some others that are equally clear. I haven't really seen this thing with awards, but that may say something about what topics I work on. @Adamant1: can you give an example and (anyone) is there documentation somewhere about what categories infoboxes add? - Jmabel ! talk 01:00, 9 June 2024 (UTC)[reply]

@Jmabel: I don't necessarily have an issue with infoboxes providing given name, surname, or birth and death dates. That's about it though. If you want an example of what I'm talking about checkout the subcategories in Category:Recipients of Russian military awards and decorations. Like categories for people that have won the various "X Years of Victory in the Great Patriotic War 1941–1945" medals. For instance Category:Heydar Aliyev, where there's like 30 categories for minor awards that I assume were all added by the infobox and can't be removed or edited. The whole thing is totally ridiculous overkill. --Adamant1 (talk) 01:11, 9 June 2024 (UTC)[reply]

How do we decide which military awards are notable enough for a category, though? Trade (talk) 01:42, 9 June 2024 (UTC)[reply]

The same way we decide anything else of the sort. It does seem odd for the decision to be hidden in a template. - Jmabel ! talk 01:44, 9 June 2024 (UTC)[reply]

Interesting territory, and there I think that we need to take a bit of a step back. The first question has to be whether the category should exist here, prior to what and how it is populated. Only after that can we then discuss the means that we want things populated, and whether they are falling into a variation of Com:OVERCAT. I don't mind cats coming from WD data as long as it is sustainable and comparatively easy to manage and resolve. It is the deep/problematic dives that we need to resolve, either in the finding or in the fixing.  — billinghurst sDrewth 02:18, 9 June 2024 (UTC)[reply]

That's an excellent point by @Billinghurst. Fundamentally, we should be creating good categories and populating them in compliance with Commons category policies  first and foremost, regardless of how this is done, be it manually or using templates and other tools. I agree very strongly with @Adamant1 that some of these categorization schemes (e.g. "recipients of X award") which clearly are really about storing data points about a topic in the form of categorization are not good form, as they aren't really about categorizing media, but trivial categorization of topics, which is not the purview of Commons. Josh (talk) 15:31, 10 June 2024 (UTC)[reply]

@Jmabel: The code is in {{Wikidata infobox}}, which should be documented on that page.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:36, 9 June 2024 (UTC)[reply]

But as far as I can see it is not at all documented there; not even the mechanism (buried somewhere other than the code on that page) is documented. It's not at all clear where one would look to see what properties/categories are handled this way. - Jmabel ! talk 01:48, 9 June 2024 (UTC)[reply]

Template:Wikidata Infobox/core documentation mentions "awards", but doesn't indicate what Wikidata properties are involved. - Jmabel ! talk 01:51, 9 June 2024 (UTC)[reply]

I think Wikidata could be helpful for populating categories about video games, movies, television shows and animes. Adding the correct categories by hand is somewhat of an tedious process Trade (talk) 01:41, 9 June 2024 (UTC)[reply]

Wikidata Infoboxes provide given name, surname, and birth and death dates, and "living people", which should presumably be uncontroversial. I'd dispute that! Broad categories like "living people" or "2000 deaths" have limited utility on Commons. There are extraordinarily few situations where they are genuinely useful as a means of locating media. Omphalographer (talk) 02:00, 9 June 2024 (UTC)[reply]

Bollocks. The Commons category structure has been an untenable mess for years. A large part of the problem expressly lies with editors from Wikidata and Wikipedia who bring their baggage with them and fail to understand that Commons is a separate site with its own policies. A prime example of the Wikidata side of the problem is with the "Births in" categories. These editors have actively sandbagged a clear segregation from "People of" categories, resulting in a massive clusterfuck of superfluous categorization and a failure to understand what a meta category actually is, as opposed to what they personally think a meta category should be. In the few times where Commons admins have crossed paths with me in attempting to clean up this mess, I gained the impression that those admins had zero understanding of COM:CAT. However, let's not get bogged down with examples, because the problem's a lot bigger than any example.RadioKAOS (talk) 02:05, 9 June 2024 (UTC)[reply]

What's the issue with editors from Wikipedia? Trade (talk) 02:20, 9 June 2024 (UTC)[reply]

@RadioKAOS: I am very comfortable with us using WD data to categorise here. My issue primarily is how we fix it when it goes askew. Our categories, our categorisation, and decision-making how we use WD data to categorise here. We will always face the issue of implementation of decisions from contributors who edit elsewhere, so the issue isn't their ideas, it is the consensus they need to reach in its implementation, instead of unilateral implementation.

So for the moment, rather than stray into the "whataboutism" it would be nice if we focus on the issue, rather than inflate to a blame game.  — billinghurst sDrewth 02:27, 9 June 2024 (UTC)[reply]

@Billinghurst: Not to point fingers at Wikipedia users, but I think it gets to one route cause of the problem, which is that it seems like people from other projects use categories as a rudimentary way to store (or display) information about a subject. Not necessarily organize media related to it. Like with the example of categories related to awards, if you look at Category:Ivan Matyukhin there's 10 categories for awards that they have received but absolutely zero images in the category having to do with them.

So the categories are just being used as rudimentary ways to store and display biographical facts about Ivan Matyukhin, not to organize media related to the awards. And again not to point fingers, but I don't think that's something regular users of Commons would do on our end. Regardless, I think the problem could largely be solved if we were clearer about (and better enforced) the idea that categories are intended to group related pages and media. Not act as shoo-ins for Wikidata data item's or something. But then we don't have the ability to do that if the categories are being automatically created and added by the infoboxes either. So... --Adamant1 (talk) 11:37, 9 June 2024 (UTC)[reply]

@Adamant1: Creation of a cat and the population of a cat are different and separate acts. For WD, they are also both happening here, not at WD, as they are in templates that we control. Someone has created the category and someone has added the code to Template:Wikidata infobox for the population to occur. The automation thereafter is due to having created the cat, and done the coding to add the cat, the population is from data at WD. If that is the issue, then can we please address that in a different thread. At this time, it is the ability to locate and identify from where the categorisation is taking place and resolving that.  — billinghurst sDrewth 01:21, 10 June 2024 (UTC)[reply]

@Billinghurst If I understand you correctly, it seems what you are saying is that it is not the automation per se that is the problem, but instead our process of having created these kinds of categories in the first place...if Category:Ivan Matyukhin exists and the 10 'Category:Recipient of...' categories exist, we can hardly blame the automated tool for adding those presumably accurate connections, but instead it rests on us as a community to have the deeper discussion and develop a consensus on how much of this kind of categorization we should have in the first place. Am I reading you correctly? Josh (talk) 15:41, 10 June 2024 (UTC)[reply]

@Billinghurst If I understand you correctly, it seems what you are saying is that it is not the automation per se that is the problem, but instead our process of having created these kinds of categories in the first place...if Category:Ivan Matyukhin exists and the 10 'Category:Recipient of...' categories exist, we can hardly blame the automated tool for adding those presumably accurate connections, but instead it rests on us as a community to have the deeper discussion and develop a consensus on how much of this kind of categorization we should have in the first place. Am I reading you correctly? Josh (talk) 15:41, 10 June 2024 (UTC)[reply]

@Joshbaumgartner: My original point, is the fixing of problematic categorisation which was the primary reason for my raising the issue. These are all categories that are created by us, and the coding in the templates is by us, either through WD infobox or other Commons templates. Finding how and where to fix things is increasingly becoming difficult, and I am looking for solutions there. We need to show how it gets there, and either how to fix it, or where to request the remedy, AND we cannot be relying on individuals. [So a clear means to identify auto-populated cats, and in the documentation in the template to show it autopopulates and where.]

My second point is that we own our categories and their creation. If we allow them to exist, then auto-population is okay, though the criteria in my first point needs to be met. Point 2 cannot exist in isolation.  — billinghurst sDrewth 04:02, 11 June 2024 (UTC)[reply]

I fixed a few cases when trying to work on categories stuck in Category:Non-empty category redirects. This concerned mostly categories on category pages (not files) and -- beyond the question which name to choose -- the categorization itself was rarely controversial. (There is some debate about the "old map" and "historical map" categories at Module_talk:Messtischblatt, categorization added for years).

Categories added by Template:Topic by country are actually relatively straightforward, but that template did lack documentation (somewhat improved yesterday). They can highlight problems in our category tree. Wikidata was rarely much of an issue. (I did blame it by error when a category was added with &html entities).

A search in the source text of Template: or Module: namespace usually finds the definition of a categorization. "|setscats= " in template documentation is meant to help. A general problem with categories added by templates is that everything needs to be refreshed if it's changed. Once one was identified a search with PetScan on subcategories of Category:Non-empty category redirects helped find other problematic uses. I noted some finds on User talk:RussBot/category redirect log. Enhancing999 (talk) 09:14, 10 June 2024 (UTC)[reply]

To me this is that if a template categorises other pages, then the template needs to specifically say that is its purpose, and give clear statements of what it is doing, ie. where to expect to see results. Ideally I would like to see a complete list of categories that it populates as that makes reverse finding useful. I would also like to see categories that are populated automatically also have a maintenance category that says that can be autopopulated by such and such template. Clarity is gold in these situations. If there is a master template for broad categorisation, then it should have a section for problems noted, and it should be identified for watching by numbers of people. (fixing problems early before they propagate is also gold)  — billinghurst sDrewth 04:27, 11 June 2024 (UTC)[reply]

Not sure how practical that is. Potentially it could mean that one would have to edit every parent category (A of X, B of X, C of X) for each subcategory (NEW of X) instead of just a category.

Unless we find a central way to add them, this could mean that for 250 new categories one would have to edit every occurrence of several parent categories (All A of .., All B of .., All C of ..), possibly thousands. Enhancing999 (talk) 12:18, 11 June 2024 (UTC)[reply]

Thanks a lot @Billinghurst: for starting this RfC, I totally agree with your description of the problems that templates can create. So we need to:

• inventorize the problems
• give solutions, how can we address these problems.

 Agree Templates are often a great tool, for instance for the date categories and the template that is importing information from wikidata (as long as it is limited to the basic categories, like given name, surname, birth and death dates (useful to decide whether works of an artist are in PD), people/men/women by name).

But I am struggling too often with automatic categorisation by templates, and indeed Template:Topic by country is one of them (others are about photographers). Some of my problems:

1. The template is automatically adding parent categories that do not exist for that country, while a parent of it or another alternative category does exists, and/or there are not enough files or subcategories to justify creating the red one (and it is a lot of work to create new ones over and over again, which I consider part of the "administrative burden" Billinghurst is talking about).
2. Sometimes there is even a better child category for a country/location than the automatically added one (for instance for the photographer by location by date: the standard parent is the location, but sometimes "history of location" or even a category that groups all the photographers together for the location and/or date would be better).
3. Some templates make use of lists or other pages that I cannot find, they might be hidden, but anyway not documented (with links) in the template.

Though it is indeed probably a side thing, I agree with Adamant1 that there are editors who create categories, just because there is a Wikidata item or an EN-WP category/page with the same name, no matter whether we need them on Commons or not. And then it is a lot of work to put that right again. That also contributes to the administrative burden.

Suggestions for solutions:

• Before you intend to create a new template that is more complicated than a simple date template: present your proposal to the community (at least in plain English, you might of coarse also present (a part of) the proposed program), ask for comment. Same for adding automatically new parent categories by a WD template.
• Good documentation should be a basic feature in each template, before a new one is published or in use:
  • in plain English, like functional specifications; explaining what the template does (what actions), how it does it ( mechanisms and for instance: what lists/other things/links it uses), when to use it (in what kind of categories) and how to use it (what exactly should you do to make it work). Written with people in mind who know nothing or very little of programming, but are interested in templates. This should also be checked and done for existing templates as well.
  • technically, for editors who will solve problems when the creator is not available.
• A procedure for when a template creates trouble:
  • Where to drop the problem?
  • Who is going to solve it? Especially when the original creator is not available (or refuses to solve it, what I have experienced as well).
  • Can we remove the template and add better parent categories (and often a navigation template) instead? Without the risk that the next editor will reverse it?

JopkeB (talk) 06:39, 11 June 2024 (UTC)[reply]

 Question@Mike Peel: do you have a system-based solution for how we can readily identify the categories that are/can be populated from WD (and thinking as maintenance cats) if it isn't already. What is done at WD end, and what can be done at Commons end to be clearly overt?  — billinghurst sDrewth 00:56, 12 June 2024 (UTC)[reply]

So taking the next step, what exactly do we want to achieve?

Starting simple, what if anything do we want to achieve at

• Commons:Templates
• Commons:Template documentation
• Commons:Wikidata or Commons:Wikidata infobox help

and without getting into the detail, where else are we looking to get information into place, or where might we need clear procedural change, or mention of expectations.  — billinghurst sDrewth 00:50, 12 June 2024 (UTC)[reply]

It looks like the guidelines are roughly speaking OK, perhaps just some additions. The main issues might be applying and enforcement. JopkeB (talk) 07:42, 14 June 2024 (UTC)[reply]

• 
• 
• 

These type of coin operated 'game' machines are usualy only found in funfairs, but in Japan these are in permanent shops. I hesitade to call these shops, but how should we classify them?

• 
• 

These kind of overhead power distribution is very common in Japan. Wich category? Smiley.toerist (talk) 09:30, 10 June 2024 (UTC)[reply]

For the second question: Category:Pole-mounted transformers in Japan I suppose. Alexpl (talk) 13:19, 10 June 2024 (UTC)[reply]

@Smiley.toerist: In British English I'd call the first kind of thing an "amusement arcade". They're quite common in seaside resorts here. And we've got Category:Amusement arcades in Japan which seems to cover the right kind of thing. --bjh21 (talk) 13:48, 10 June 2024 (UTC)[reply]

• 

This machine is basicaly an ticketing machine, but it has also a money change function where banknotes are exchanged for coins.Smiley.toerist (talk) 22:35, 15 June 2024 (UTC)[reply]

I have found this on flickr[1]. It is a photo of an original picture held in the Royal Library, Copenhagen. It is described, in:
Niklas Eriksson & Johan Rönnby (2017) Mars (1564): the initial archaeological investigations of a great 16th‐century Swedish warship, International Journal of Nautical Archaeology, 46:1, 92-107, DOI: 10.1111/1095-9270.12210 [2]
as "Illustration from a Danish manuscript, signed Rudolf van Deventer 1585".

The flickr version claims copyright – but presumably that is only copyright of the photograph. The illustration itself is clearly over 400 years old.

Is there any route through the various copyright laws that would allow a version of this picture to be uploaded to commons? Obviously, as well as the flickr version, there is the one in the paper listed above. There is also a cropped version in
Niklas Eriksson (2019) How Large Was Mars? An investigation of the dimensions of a legendary Swedish warship, 1563–1564, The Mariner's Mirror, 105:3, 260-274, DOI: 10.1080/00253359.2019.1615775 (Open access[3])
Other pictures of the wreck of this vessel look to be heavily protected in copyright law, so this old picture would be of real value. ThoughtIdRetired (talk) 19:28, 10 June 2024 (UTC)[reply]

You can upload it and tag with a {{Pd-art}} template. Ruslik (talk) 20:02, 10 June 2024 (UTC)[reply]

More precisely, {{PD-Art|PD-old-100-expired}}. - Jmabel ! talk 03:46, 11 June 2024 (UTC)[reply]

Is this category for flags that are fictional? Or is it for flags for countries featured in creative works? There is no way to infer this from the category name alone Trade (talk) 22:21, 10 June 2024 (UTC)[reply]

As I've interpreted it, it's both - they're flags which are fictional, and which have appeared in fictional works. I'm not sure how you'd have one without the other. Omphalographer (talk) 05:00, 11 June 2024 (UTC)[reply]

Also note: We're keeping flags from notable works of fiction there. Files that are just about personal fiction (look at the awesome symbols of the micronation my roleplaying group founded yesterday) should get deleted as soon as possible. And see also the Category:Fictional flags of historical entities (to be replaced and deleted), now that category name should speak for itself. --Enyavar (talk) 07:47, 11 June 2024 (UTC)[reply]

Right, so we are we showing both type of flags into the exact same category? This is just a mess to keep track of Trade (talk) 18:22, 11 June 2024 (UTC)[reply]

What do you mean by "both types"? As far as I'm aware, there is (or should be) only one type of image in this category - depictions of flags which stem from fictional works, and which represent countries which only exist within those works of fiction. A typical example would be File:Gilead-Flag.gif, the flag of the fictional country of Gilead from The Handmaid's Tale. Omphalographer (talk) 18:31, 11 June 2024 (UTC)[reply]

There is nothing in the category nor it's name to indicate that only flags from creative works should be features. Trade (talk) 22:24, 12 June 2024 (UTC)[reply]

I could be totally off base here but I've done some work in the area and I think at least some of the problem is the ambiguity of the parent categories and how the whole thing is structured going up from there. For instance the category has both Category:Flags in fiction and Category:Special or fictional flags as parents. But then Category:Special or fictional flags is also a parent of Category:Flags in fiction. So it's just circular. Plus the Wikidata entry for Category:Special or fictional flags appears to be about "unofficial flag", which really has nothing to with fictional flags to begin with. Regardless, it seems like this combines "special", "fictional", and "unofficial" flags into the same category and does it in a way were the categories are just circular. We should just pick a term, go with it, and make the parents categories actually lead somewhere meaningful. --Adamant1 (talk) 00:06, 13 June 2024 (UTC)[reply]

How about "Flags of countries from creative works"? This could then be a subcategory of "Flags from creative works", with it being a subcategory of "Symbols from creative works" Trade (talk) 21:57, 13 June 2024 (UTC)[reply]

I think not. That could as easily mean fictional flags of real countries as flags of fictional countries. - Jmabel ! talk 01:10, 14 June 2024 (UTC)[reply]

Fictional flag does not equal Flag from creative work Trade (talk) 14:00, 15 June 2024 (UTC)[reply]

In compliance with the provisions of the US Digital Millennium Copyright Act (DMCA), and at the instruction of the Wikimedia Foundation's legal counsel, one or more files have been deleted from Commons. Please note that this is an official action of the Wikimedia Foundation office which should not be undone. If you have valid grounds for a counter-claim under the DMCA, please contact me.

The takedown can be read here.

Affected file(s):

• File:बाणभट्ट की आत्मकथा.pdf (|talk|history|links|watch|logs)

To discuss this DMCA takedown, please go to COM:DMCA#Autobiography of Banbhatta. Thank you! Joe Sutherland (WMF) (talk) 23:03, 10 June 2024 (UTC)[reply]

Do we have any guidelines on how to name categories on Commons for specific concerts? I feel like there is a lot of freedom. Maybe it would be worth developing a scheme such as: Artist name - Place - Date or different in a specific format? Example of diversity in naming: c:Category:2013 concerts in the United States Gower (talk) 05:47, 11 June 2024 (UTC)[reply]

I believe we do not have such a standard, and doubt we need one. - Jmabel ! talk 12:41, 11 June 2024 (UTC)[reply]

It probably depends on the artist and concert but I don't think the place or date needs to be in the name of the category in a good perecentage of cases. That's what parent categories are for. --Adamant1 (talk) 13:07, 11 June 2024 (UTC)[reply]

a lot of times categories for events are just titled according to their official names. sometimes when that name is not special enough a year, a date or a location is appended in parentheses, e.g. (2024) or (London).

it certainly helps if you choose to name your categories in a very detailed format. imo, a format of "concert name (yyyy-mm-dd)" is good enough, because quite rarely there would be two concerts of the same name on the same date? if the concert has no name, then "artistname's concert (yyyy-mm-dd)". if there are multiple artists involved then "Concert at venuename, city (yyyy-mm-dd)". RZuo (talk) 07:20, 12 June 2024 (UTC)[reply]

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Hi everyone,

The final text of the Wikimedia Movement Charter is now up on Meta in more than 20 languages for your reading.

What is the Wikimedia Movement Charter?

The Wikimedia Movement Charter is a proposed document to define roles and responsibilities for all the members and entities of the Wikimedia movement, including the creation of a new body – the Global Council – for movement governance.

Join the Wikimedia Movement Charter “Launch Party”

Join the “Launch Party” on June 20, 2024 at 14.00-15.00 UTC (your local time). During this call, we will celebrate the release of the final Charter and present the content of the Charter. Join and learn about the Charter before casting your vote.

Movement Charter ratification vote

Voting will commence on SecurePoll on June 25, 2024 at 00:01 UTC and will conclude on July 9, 2024 at 23:59 UTC. You can read more about the voting process, eligibility criteria, and other details on Meta.

If you have any questions, please leave a comment on the Meta talk page or email the MCDC at mcdc@wikimedia.org.

On behalf of the MCDC,

RamzyM (WMF) 08:44, 11 June 2024 (UTC)[reply]

After reading it, I noticed that:

• Charter refers some "community leadership" as teh accountable body for each Wikimedia project, without defining what it means (the whole community, some specific members?);
• Charter rules over all Wikimedia project policies, but not over those of the Wikimedia affiliates and the WMF;
• Charter leaves WMF out of the Global Council (community + affiliates), as an independent body at the same power level;
• While the whole community, including affiliate people, get to elect 12 seats out of 25 in the Global Council, affiliates themselves get an additional 8 seats for themselves, which I considere a severe and totally unjustified unbalance of power towards affiliates;

I don't think this is acceptable, and will certainly vote to block this charter. I advise you to read it carefully, and eventually block it as well, as I don't see how this could favor our community. Darwin ^Ahoy! 16:06, 13 June 2024 (UTC)[reply]

Hello all! We're happy to share that we will work on logo detection in the following months and that we defined an initial approach for this.

You can read more at the project page and you can have your say in the project's talk.

We want your feedback on it, and we need your insights on how to further tune the detection tool.

Thanks for your attention! Sannita (WMF) (talk) 13:54, 11 June 2024 (UTC)[reply]

I'm rather confused. The general feed back seemed to me to amount to "logo detection isn't very useful." I was told by a couple of people when I asked informally, "Don't worry, it isn't like logo detection isn't the goal, this was just a side effect of work on something else that someone thought might be useful." And now you say that further work is proceeding on this front? What, exactly, put this on the front burner, especially given that we are constantly being reminded that dev has very limited resources for Commons? What is the problem we are trying to solve? - Jmabel ! talk 22:25, 11 June 2024 (UTC)[reply]

@Jmabel Our impression, to be fair, was quite the opposite: that it was something that could be useful in dealing with the third-most frequent rationale for requests for deletions (the first two being copyvios and FoP, which we found it was impossible to tackle in an automated way). There was more difficulty in defining how this could be implemented, but not on its usefulness. This is why we are re-opening the feedback period, to understand how it could be implemented. Sannita (WMF) (talk) 10:36, 13 June 2024 (UTC)[reply]

@Sannita (WMF) "third-most frequent rationale for requests for deletions (the first two being copyvios" - This doesn't make sense at all. The only reason we would delete a logo is because it's a copyvio, not because its a logo. There are scores of logos which are in the public domain, either by age or by lack of creativity, while others get licensed under free licenses. I'm not sure why we should discourage people of uploading that specific content with such a warning, when those exact same rules apply to everything else. As it is, I tend to not support that implementation. And as JMabel mentioned, it's disheartening to see that resources were wasted developing such an apparently useless tool, when there are clearly established priorities (see the old wish lists, for instance). Darwin ^Ahoy! 16:16, 13 June 2024 (UTC)[reply]

@Sannita (WMF), Jmabel, and DarwIn: I'll leave others to decide on the best or most suited UI for the logo detection. As for the feature, I am supportive of this, but conditionally. Suggest this feature should be mandatory for users who do not have the appropriate user rights; I suggest users who are not admins/sysops, license reviewers, and/or autopatrolled. Users who are under these three tiers of user groups are free to upload logos and should not be slapped with this filter, since they are already aware of copyright issues and TOO considerations for logos. If possible, the feature should effectively block uses of "FileExporter" and other cross-wiki file transfer tools. And one more thing, I suggest the filter can prohibit new users (those who are not autoconfirmed) from uploading or importing logos (even photos showing logos that are non-de minimis/non-incidental). Hopefully, this will trim down at least a third or less (my guess) of deletion requests that contribute to the perennial backlogs. There are many more areas in Commons that also need attentions and resolutions, like Commons:Categories for discussion/Older (some open discussions were from before the lockdown era of 2020). JWilz12345 (Talk|Contrib's.) 08:30, 14 June 2024 (UTC)[reply]

@JWilz12345: I think the plan is for this to become a secret feature. It has no effect on the upload itself and nobody but the uploader will know about the warning. Possibly, the same effect could have been achieved by merely editing the current interface and noting "if it's a logo, follow logo guidelines". Enhancing999 (talk) 08:43, 14 June 2024 (UTC)[reply]

Just my opinion, but having a specific warning to the uploader saying the image might be a logo seems rather pointless. If not borderline condensing towards users. People generally know what they are uploading images of. The less clear thing is what license to use in any specific instance and I don't really how this deals with that. A better thing would probably just be a specific checkbox for logos that automatically adds a license and puts the image in a specific category for images that need reviewing on upload. Otherwise people are just going to just ignore the warning just like they are already ignoring guidelines by uploading the image to begin with. What we really need is better ways to review and deal with problematic images on our end though. Not try to unload that on uploaders by over complicating the UploadWizard with a bunch of warnings, extra boxes, and the like. --Adamant1 (talk) 20:52, 15 June 2024 (UTC)[reply]

@Adamant1: anything related to copyright is already complicated enough. That's perhaps a price to pay for establishing/creating a free media repository site like Commons, or more so, Wikipedia itself way back more than 20 years ago. Something that founders Wales and Sanger likely did not forseen or anticipate. (Note: just a part of my thoughts, and not a representative of my general perspective on Wikimedia movement, which I still support in the context of mandating global FoP). JWilz12345 (Talk|Contrib's.) 21:12, 15 June 2024 (UTC)[reply]

Thank you to everyone who has provided feedback on renaming the Community Wishlist Survey. We now have 3 names for you to choose from:

1. Community Ideas Exchange

2. Community Feature Requests

3. Community Suggestions Portal

You are invited to vote for one that works for you. –– STei (WMF) (talk) 15:07, 11 June 2024 (UTC)[reply]

What's the cost of this rename to WMF? Do we really need to spend resources on this rather than actually doing some development? Enhancing999 (talk) 19:01, 11 June 2024 (UTC)[reply]

Does the 15-16 June 2024 Ukraine peace summit logo consist "entirely of a simple geometric combination of shapes and text"? The official alt text describes the ring pattern as "overlapping blue and yellow circles". I see them rather as 10 greyish concentric annuli and 10 yellowish concentric annuli with a partial transparency rule used to show the intersecting parts. So rather simple, but not completely trivial. The Swiss flag is on there too, and that is geometrically very simple and has at least one PD version on Commons.

So does this logo count as a free logo under the simple geometric combination argument, as described at w:Wikipedia:Logos#Copyright-free logos? Is it uploadable to Commons? Boud (talk) 20:00, 11 June 2024 (UTC)[reply]

@Boud: Looks OK. In the future, when providing links, it is much preferred not to use URLs that result in downloads to the file system of the computer that is accessing. - Jmabel ! talk 22:35, 11 June 2024 (UTC)[reply]

OK, cool - thanks! Regarding the URL, I don't see how it's possible to provide a URL to a file that does not result in downloading the file. Without downloading the file, the file cannot be viewed.

But you also refer to storage in a file system. My guess is what you mean is that it's better to provide a URL that can be used to view an image in a browser tab - in which case the file is downloaded and stored in RAM and very likely also in a cache on a file system, which the user will generally not notice. I did notice that that my browser refuses to display that file in a tab using that URL. Just now I found that removing /jcr:content/renditions/original is sufficient for browser display of the file, in which the file is only stored in RAM and in a cache area of the file system - so thanks for the tip :). I guess jcr:content/... redirects to a script which insists on downloading and storage in a file system and refuses to allow downloading and displaying in a browser tab. Boud (talk) 23:01, 11 June 2024 (UTC)[reply]

Yes, everything is likely cached, but normally when you browse to a page you don't need to explicitly delete it to free the disk space back up. - Jmabel ! talk 23:18, 11 June 2024 (UTC)[reply]

By the way, for copyright expertise, Village pump/Copyright is generally a better place to ask. - Jmabel ! talk 22:36, 11 June 2024 (UTC)[reply]

OK, thanks, noted. Boud (talk) 23:01, 11 June 2024 (UTC)[reply]

Hi, I was wondering if there could be a mechanism for requesting a map be made? — Preceding unsigned comment added by Alexanderkowal (talk • contribs) 20:08, 11 June 2024 (UTC)[reply]

@Alexanderkowal: Commons:Graphic Lab/Map workshop - Jmabel ! talk 22:37, 11 June 2024 (UTC)[reply]

Thank you Alexanderkowal (talk) 12:22, 12 June 2024 (UTC)[reply]

Hey-- Is the Weibo Watermark in the lower right of this image advertising per Commons? File:全景图 深圳湾公园 远看香港 - By 科技小辛 - panoramio.jpg --Geographyinitiative (talk) 22:19, 11 June 2024 (UTC)[reply]

It is not a reason not to host the photo, assuming that is what you are asking. - Jmabel ! talk 22:39, 11 June 2024 (UTC)[reply]

e.g. cat that includes both president of france visiting london and king of norway visiting london?

existing cat structure for a specific person visiting other countries is Category:Politicians in foreign countries. RZuo (talk) 09:27, 12 June 2024 (UTC)[reply]

See for example Category:Visits of foreign politicians to Germany. However from what I can see only few countries have such a category so far and there is no common parental "visits .. by country" category. --A.Savin 12:22, 12 June 2024 (UTC)[reply]

Strangely the hierarchy brings President Biden visiting Russia. Enhancing999 (talk) 19:14, 12 June 2024 (UTC)[reply]

When I name a file on my Windows PC in a folder, and then upload using the wizard, underscores and or dashes appear in the file name. How to stop it from doing that? -Broichmore (talk) 14:45, 12 June 2024 (UTC)[reply]

@Broichmore: Spaces get converted to underscores (if necessary) for URL purposes, but both are stored as spaces and can be used either way (I find the underscores ugly, and so does AutoEd). What is getting converted to dashes for you?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 16:09, 12 June 2024 (UTC)[reply]

MediaWiki will generally convert characters not allowed in filenames to dashes. Typically that means : / \ < > [ ] | # { } but can also include more obscure characters, such as control characters. Bawolff (talk) 19:12, 12 June 2024 (UTC)[reply]

• That is by design, it can be annoying when you want to download, and then reupload to another website and use the filename as a description of image. You then have to remove the underscores by hand. --RAN (talk) 19:03, 12 June 2024 (UTC)[reply]

See Commons:Deletion requests/سرآسونٱ Jarekt (talk) 01:08, 13 June 2024 (UTC)[reply]

Why was this picture deleted with speedy deletion criteria? There is an article in the Hebrew Wikipedia about Yuval Karniel. This is a very puzzling deletion. See Category:Yuval Karniel. I am a VRT volunteer, and the photographer User:Pinhas stern contacted VRT system and asked why it was deleted. Hanay (talk) 05:03, 13 June 2024 (UTC)[reply]

• @Hanay: The respective user may request an Commons:Undeletion requests if the deletion may be inappropiate --PantheraLeo1359531 😺 (talk) 09:37, 13 June 2024 (UTC)[reply]

  @PantheraLeo1359531 He requested it through VRT, why is that not enough? I didn't get any satisfactory explanation why the picture was deleted. @Geagea Maybe you can explain it to me? Thanks Hanay (talk) 11:56, 13 June 2024 (UTC)[reply]

  Undeleted. Obvious mistake. -- Geagea (talk) 12:03, 13 June 2024 (UTC)[reply]

  Thank you Hanay (talk) 12:16, 13 June 2024 (UTC)[reply]

  Pinging @Alachuckthebuck as tagger per COM:CSD#F10 and Kadı as deleting Admin; the uploader has over 8,000 constructive global contributions.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:15, 13 June 2024 (UTC)[reply]

  @Geagea, @Hanay, @Jeff G.: Thank you all for notifying me. Sorry for this. Best wishes. Kadı Message 14:24, 13 June 2024 (UTC)[reply]

It's concerning that this comes just days after I notified Alachuckthebuck about similar incorrect F10 tagging. Pi.1415926535 (talk) 19:45, 13 June 2024 (UTC)[reply]

Hi!

It feels like the servers' performance seems to be decreased compared to the last weeks. Database queries take a lot longer, file publishing sometimes has a huge delay, and also the amount of uploaded files and data has decreased considerably. Do you experience this, too and what could be the reasons? Greetings --PantheraLeo1359531 😺 (talk) 08:49, 13 June 2024 (UTC)[reply]

@PantheraLeo1359531: This may have something to do with phab:T363622.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:11, 13 June 2024 (UTC)[reply]

Thanks :) --PantheraLeo1359531 😺 (talk) 13:39, 13 June 2024 (UTC)[reply]

I was trying to edit my watchlist to reduce it .. but that times out too. Enhancing999 (talk) 13:16, 13 June 2024 (UTC)[reply]

@Enhancing999: I got the following when I tried:

MediaWiki internal error.

Original exception: [f497cc8d-d5a6-4ad1-95eb-db2be5de539e] 2024-06-13 13:19:30: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

Exception caught inside exception handler.

Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.

  — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:22, 13 June 2024 (UTC)[reply]

Special:EditWatchlist/raw works. Enhancing999 (talk) 13:30, 13 June 2024 (UTC)[reply]

@Enhancing999: Thanks, but "Not enough memory to open this page" is not exactly a ringing endorsement.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 03:19, 14 June 2024 (UTC)[reply]

The file that I uploaded File:An illustration of a Swedish warship, probably Mars, under attack by a Danish ship.jpg has a warning of deletion as the copyright status is unclear. This is a reproduction of an illustration made in the year 1585. I have sourced it from its appearance in an academic paper, though it is also available on flickr (both sources given with the file). Have I met all the requirements or am I still missing something? Thanks, ThoughtIdRetired (talk) 20:36, 13 June 2024 (UTC)[reply]

@ThoughtIdRetired You uploaded the file without a license, so the bot came and tagged it. Next time this happens simply remove the deletion notice after fixing the license. Darwin ^Ahoy! 21:42, 13 June 2024 (UTC)[reply]

Thanks, though I have to say that removing the deletion notice sounds a bit like marking your own homework. For some reason I have never felt totally comfortable with my level of understanding copyright law, which might explain that sentiment. And that bot must have worked pretty quickly on this occasion, because in the past I have often uploaded with the wrong or a missing licence then immediately edited with the correct licence from a file that I know to have an identical copyright situation. ThoughtIdRetired (talk) 22:14, 13 June 2024 (UTC)[reply]

@ThoughtIdRetired: if you are less than fully confident, then rather than just remove the tag, start a DR, and in the DR, note what you did. - Jmabel ! talk 01:06, 14 June 2024 (UTC)[reply]

Can you decode "DR" for me? Thanks. ThoughtIdRetired (talk) 10:32, 14 June 2024 (UTC)[reply]

That would be a deletion request. --Robert Flogaus-Faust (talk) 13:30, 14 June 2024 (UTC)[reply]

& @ThoughtIdRetired: Good stuff! Any idea why the cannonballs have flames from both sides, were they incendiary cannonballs? Was it a special weapon, or just an artist never drawing a cannonball before. --RAN (talk) 14:55, 14 June 2024 (UTC)[reply]

Our original upload in 2014 describes this picture as The battle between the Danish and Swedish admiral ships Jägmästaren and Sankt Erik. The image was used en:Action of 7 July 1565. Broichmore (talk) 15:54, 14 June 2024 (UTC)[reply]

Looking at a larger image, they seem to be incendiary cannonballs. -- Asclepias (talk) 16:39, 14 June 2024 (UTC)[reply]

The paper cited as the source argues that the ship is "probably" Mars. The arguments seem reasonable as this is a two decked ship (rare at the time, certainly in the Baltic) which caught fire in battle and ultimately exploded. I would suggest taking a look at the two archaeological papers cited in the article on Mars. Frustratingly, there are different historical accounts of the action – it probably doesn't help that the Swedish admiral involved was a bit of a celebrity. I take it that the cannon balls are incendiary ammunition – the original source of the illustration was a treatise on naval gunnery, so it seems. ThoughtIdRetired (talk) 20:39, 14 June 2024 (UTC)[reply]

Many thanks. I'll leave it to you to cross refer notes on the two images. Also, same for whether or not Deventer is a von or a van? Once you decide, I'll enter him into Wikidata. Last, the cannballs, this is actually en:Chain shot of a kind? Broichmore (talk) 22:18, 14 June 2024 (UTC)[reply]

Please undelete File:לירן כוג'הינוף - עותק.jpg. There is VRT permission for this file. Thanks Hanay (talk) 00:29, 14 June 2024 (UTC)[reply]

• {@Hanay: then take that up on Commons:Volunteer Response Team/Noticeboard or start an undeletion request rather than discuss here on the Village pump. - Jmabel ! talk 01:08, 14 June 2024 (UTC)[reply]

  Thank you Hanay (talk) 04:57, 14 June 2024 (UTC)[reply]

  • I think @Hanay had already been asked to do that above. Is there a reason you are posting this here instead? Enhancing999 (talk) 08:44, 14 June 2024 (UTC)[reply]

    I did not. This is another picture. Hanay (talk) 14:02, 14 June 2024 (UTC)[reply]

    • But the same situation, and the same advice applies. - Jmabel ! talk 17:12, 14 June 2024 (UTC)[reply]

I recently noticed that COM:Exif is linked from Special:UploadWizard's warning that files may contain metadata. I migrated the translation to the Translate extension, and while doing so I noticed that a lot of the page is either out of date (there's advice for Windows XP) or not particularly useful to a non-technical user. I'm not in a position to rewrite it, as I only use exiftool on Linux to mess with metadata. AntiCompositeNumber (talk) 18:59, 14 June 2024 (UTC)[reply]

The Windows XP's part should probably be removed. Ruslik (talk) 20:05, 14 June 2024 (UTC)[reply]

What's the plan for the 7000+ subcategories, now that the country was moved from Category:Georgia to Category:Georgia (country)?

The discussion started in 2017 was finally closed at the beginning of the month (see Commons:Categories for discussion/2017/03/Category:Georgia).

Ideally we wont have these categories in different states for months or years. Enhancing999 (talk) 22:41, 14 June 2024 (UTC)[reply]

It clearly should have been part of the conversation. Short-sighted to not have had a plan of the extensive nature, and the migration, and whether that change should have occurred.  — billinghurst sDrewth 23:37, 14 June 2024 (UTC)[reply]

It's going to be particularly tricky for anything template-driven. - Jmabel ! talk 23:58, 14 June 2024 (UTC)[reply]

I did not take part in that discussion, but I agree with you. It might be of a big help if Cat-a-lot would work again for categories. JopkeB (talk) 08:01, 15 June 2024 (UTC)[reply]

Supposedly people involved were aware that this can imply a lot of work.

• Maybe a way to go about it could be to do it by level below Category:Georgia (country):
  • Start with the direct subcategories of Category:Georgia (country) and move those (possibly with User:CommonsDelinker/commands, not forgetting to delete existing redirects first)
  • and then do the next level (currently 284 with 34 already done: petscan:28633989).
• Template based stuff should be visible in Category:Non-empty category redirects (currently 21, petscan:28633998). This can take a while to show up there if ever.
• Eventually some redirects would need to be converted into disambiguations.

I guess we would need to find an admin to do the requests at User:CommonsDelinker/commands. I can help with Category:Non-empty category redirects. Enhancing999 (talk) 10:03, 15 June 2024 (UTC)[reply]

• Sample case: File:20230929 1 2 7 1 1 obj28606101 1.jpg ("uploaded while editing fr.wikipedia"; tagged as copyvio by me)
• Another (by same uploader): File:Hopital Arles.jpg

I don't know if someone had posted about the issues surrounding uploads made by uploaders while editing articles on Wikipedias. Several of these uploads are found by reviewers like me to be copyright violations (whether obvious or suspected), like stolen from the Internet or not freely-licensed images harvested from Flickr or other media repository sites (no prior checking of licensing compatibility).

Similar issue also arises for uploads that were made from other wikis ("cross-wiki uploads"). JWilz12345 (Talk|Contrib's.) 03:20, 15 June 2024 (UTC)[reply]

And also for uploads directly to Commons, no? - Jmabel ! talk 03:53, 15 June 2024 (UTC)[reply]

@Jmabel I'm only referring to uplpads that were made through cross-wiki or while editing Wikipedia articles. IMO, these are usually not easily detected, and many of the uploads that I see are questionable. Time to restrict cross-wiki editing to three groups only? (Only autopatrolled, image reviewers, and admins/sysops can do cross-wiki and/or while-editing-on-Wikipedia uploads.) JWilz12345 (Talk|Contrib's.) 04:23, 15 June 2024 (UTC)[reply]

Why aren't those uploads caught by the existing cross-wiki filter (153)? -- Asclepias (talk) 12:06, 15 June 2024 (UTC)[reply]

I don't know anything about coding syntax, so forgive me for this silly question, but when a change to the cross-wiki filter added an exemption for users whose user group includes the string "confirmed", did that have the unintended effect of exempting also the users who are "autoconfirmed", thus basically nullifying the main criteria of the filter? -- Asclepias (talk) 18:43, 15 June 2024 (UTC)[reply]

 Comment @Asclepias: any user_group noted is local (not at the wiki where editing) per Special:ListGroupRights and is not based on user_rights which you can note in the second of the columns. So autoconfirmed user_group is different from confirmed user_group; also noting the "confirmed" is a specific allocated right by admins, not inherited as per autoconfirmed.  — billinghurst sDrewth 01:06, 16 June 2024 (UTC)[reply]

Thank you for replying. Yes, I get that about the nature of the user groups. But my doubt was about the syntax that code the conditions of the filters. In filter 153, when the exemption condition says that accounts are exempted when the string of characters "confirmed" is found in their "user_groups", does that mean that nothing else can exist before or after strictly the nine letters "confirmed", or does that find also "autoconfirmed" because the string "confirmed" is found also in "autoconfirmed"? I'm trying to find an explanation for why uploads are not filtered when apparently they should be if the main conditions of the filter were applied. -- Asclepias (talk) 02:28, 16 June 2024 (UTC)[reply]

Another example also by the same uploader: File:Navette arles.jpg (original is this unfree Flickr image). JWilz12345 (Talk|Contrib's.) 04:24, 15 June 2024 (UTC)[reply]

why are we surprised that editors make mistakes ? Have you tried teaching them ? —TheDJ (talk • contribs) 08:16, 15 June 2024 (UTC)[reply]

@TheDJ mistakes may either be accidental or (as my experience in image reviewing suggests) intentional. The speedy deletion tags are enough to teach them the hard way. The prevalence of social media has made many netizens disrespect copyright rules; in the case of our country, it has been normal to not attribute original authors and instead go away with usage of "CTTO" or "credit(s) to the owner", even if authorities and scholars/media and information literacy instructors continue to remind Filipinos to refrain from using "credits to the owner" and cite / attribute sources and authors properly.

What I want to suggest, is to effectively disallow any cross-wiki or "edits-from-Wikipedias" uploading, except if the user belongs to three user groups – autopatrolled, license reviewer, and/or admin/sysop (the basis of user group should be the user group status at Commons, not on Wikipedias). This would hopefully trim down at least around a tenth (my guess) of possibly copyvio files. JWilz12345 (Talk|Contrib's.) 10:38, 15 June 2024 (UTC)[reply]

@JWilz12345: Please see phab:T214230.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:35, 15 June 2024 (UTC)[reply]

@Jeff G. the intention for cross-wiki uploading is good, but Wikimedia community unintentionally invited vandals and trolls to upload either out-of-scope or copyvio files seamlessly. This has resulted to numerous problematic files that needed to be reviewed and/or nuked one-by-one (image reviewing is an intense effort in which a mass deletion request could only be used as a "last-resort"). Some of these files, were only detected a year or two after upload, seemingly slipped off the supposed edit filter. In fact, I conducted some recent file reviews by finding recent WEBP images, as I can still recall the discussion at Commons:Village pump/Proposals/Archive/2023/11#Restrict webp upload. One such file I found was from a certain Alexandre071109 (talk · contribs), who uploaded numerous problematic files (in terms of copyright violations) through "upload-while-editing-Wikipedia" method.

Note that my perspective on that discussion has changed. Restricting WEBP upload does not solve things, as copyvios in PNG and JPEG file types can still be uploaded by vandals/trolls, using any easy methods in uploading. A possible viable solution is to only permit cross-wiki/"upload-while-editing-wiki" methods to experienced users. JWilz12345 (Talk|Contrib's.) 14:56, 15 June 2024 (UTC)[reply]

Still one more example, uploaded a few hours ago: File:PsychoClown5.webp, "Uploaded while editing 'List of current champions in Lucha Libre AAA Worldwide' on en.wikipedia.org." Thanks @Belbury: for the speedy deletion tag. JWilz12345 (Talk|Contrib's.) 14:59, 15 June 2024 (UTC)[reply]

Do we have any figures on how often "while editing" uploads turn out to be copyvios, compared to locally-uploaded ones? I flag a lot of copyvios in general but the connection hadn't occured to me. Belbury (talk) 15:20, 15 June 2024 (UTC)[reply]

Actually I suppose the more important question is how many "while editing" uploads are useful ones. If this is a situation where 95% are copyvios or vandalism then it might be worth changing our approach to them, but we need some proper numbers on this. Belbury (talk) 22:32, 15 June 2024 (UTC)[reply]

One more I just tagged now: File:TELEMMGLPICT000291129217 trans NvBQzQNjv4BqsJKoeWavxz5iDO 6aHC-NNzDn6JMw4oMG9nccdeVAbM.webp, "Uploaded while editing 'Polly Walker' on en.wikipedia.org" JWilz12345 (Talk|Contrib's.) 20:01, 15 June 2024 (UTC) More tagging's: files uploaded by BrainMind Diana (talk · contribs), like File:Karen-Rommelfanger.jpg (‎"Uploaded while editing 'Draft:Karen Rommelfanger' on en.wikipedia.org") and File:Buzzy picture.png ("Uploaded while editing 'Amy Baxter' on en.wikipedia.org"). JWilz12345 (Talk|Contrib's.) 20:19, 15 June 2024 (UTC) Still another that I just tagged: File:El Primo Skin-Default.webp, "Uploaded while editing 'Holliston, Massachusetts' on en.wikipedia.org" (but there was no intention to use it on enwiki article). JWilz12345 (Talk|Contrib's.) 20:48, 15 June 2024 (UTC)[reply]

Still one more thing, sharing it here as an emphasis on the problem. File:Hack.intro.webp, "Uploaded while editing 'Babhalgaon' on en.wikipedia.org." Unused on w:en:Babhalgaon, and the uploader's intention is likely trolling or treating Commons as similar to a socmed site, since it is unreasonable to use a cybersecurity-related stock image in an article of a small Indian village of 7,000+ residents that has no connection to I.T. industry or even cybersecurity experts. No obvious relation or connection, incoherent, just used cross-wiki uploading to "play"/"troll"/"test upload" (whatever that may be). On top of that, it is a COM:NETCOPYVIO. JWilz12345 (Talk|Contrib's.) 21:19, 15 June 2024 (UTC)[reply]

The entire point of Commons is (or at least was at the beginning) that Wikipedia contributors can upload images to a common repository while editing. Enhancing999 (talk) 21:56, 15 June 2024 (UTC)[reply]

Another worthwhile question might be whether we should take more steps to identify and delete "abandoned" cross-wiki uploads, where an image was uploaded from another wiki, but where the image is no longer in use there (e.g. because the edit was reverted or the target page was deleted). My intuition is that those images are particularly likely to be out of scope and/or copyvios, and a lot of them will simply be unusable due to a lack of context. Any interest in reviewing these? Omphalographer (talk) 00:35, 16 June 2024 (UTC)[reply]

•  Comment based on some of the recent commentary on the files that have been uploaded that should have been rejected, I have made a minor mod to the filter to slightly increase the file size to disallowed. There is probably a little more we can do to look to challenge files where they add a url within the "uploaded while editing ...".  — billinghurst sDrewth 02:26, 16 June 2024 (UTC)[reply]

  @Billinghurst that's a good move, at least to mitigate and reduce the degree of the problem. JWilz12345 (Talk|Contrib's.) 02:38, 16 June 2024 (UTC)[reply]

@Omphalographer with regards to the supposed Babhalgaon upload (an irrelevant stock image representing cybersecurity), based on enwiki article's history, the uploader – Balaji 7978 (talk · contribs) – did some irrelevant and one vandalism contributions, which were promptly reverted. JWilz12345 (Talk|Contrib's.) 02:38, 16 June 2024 (UTC)[reply]

Omphalographer, after some more digging on enwiki article's history, it appeared he (yes, he) added his apparent real name on the notable people section list and claimed he is from a national cybersecurity agency from India. That now explains why his only upload here was a stock image representing cybersecurity. Possibly implicit self-promotion but his upload is a copyvio anyway. JWilz12345 (Talk|Contrib's.) 02:47, 16 June 2024 (UTC)[reply]

 Comment To note that the system already produces a list of successful cross-wiki-uploads => https://commons.wikimedia.org/w/index.php?title=Special:RecentChanges&tagfilter=cross-wiki-upload <= where you will be able to determine what has or has not been deleted.

Now we just need someone to divine a query that allows us to identify those files that have got the tag and are not used. And I would guess that we are looking for those that fit that criteria in the past week; alternatively works that don't have eyeball'd categorisation.  — billinghurst sDrewth 03:32, 16 June 2024 (UTC)[reply]

From [4], I would say at least 90% of these uploads are problematic. Yann (talk) 09:42, 16 June 2024 (UTC)[reply]

{{GFDL}}-only is no longer accepted for new uploads on Commons (since 2018), English Wikipedia (since 2021) and some other wikis because GFDL is not a good license for media files. {{GFDL-with-disclaimers}} are even worse so a lot have been done for many years to get rid of them per en:Wikipedia:GFDL standardization (since 2007).

I noticed that some wikis still upload files licensed GFDL and some even with disclaimers (and more still host such files).

So if there are anyone out there that have any good ideas on how to get all wikis to stop using disclaimers and if possible also the use of GFDL-only or would like to help make that happen it would be great.

I have made a list of wikis and files uploaded with GFDL (table below only have a few of the wikis and it is just to illustrate):

Language/category	Number of files	Remarks
w:af:Kategorie:GFDL-beelde	182
w:als:Kategorie:GFDL-Bild	24
w:an:Categoría:Imáchens GFDL	13
w:ar:تصنيف:صور رخصة جنو	552
w:en:Category:GFDL files with disclaimers	10,914
v:it:Categoria:Immagini GFDL	34
v:ru:Категория:Файлы:GFDL	7
voy:en:Category:GFDL files	13
m:Category:Presumed GFDL images	459

The full list is located at m:User:MGA73/GFDL files.

I noted some idea at m:User:MGA73/Status#How_to_help_cleaning_up_GFDL and basicly it is stop upload of new files, clean up existing files, move the good files to Commons (if possible) and delete the bad files. (If possible also fix m:File metadata cleanup drive.)

But that will only work if someone does something and it goes a lot faster if many help :-) --MGA73 (talk) 07:26, 15 June 2024 (UTC)[reply]

Nice, thanks for making the list! —TheDJ (talk • contribs) 08:18, 15 June 2024 (UTC)[reply]

File:Drake Milligan at The Brick Bar Oxford Ohio.jpg is clearly mirrored, as all other images of Drake Milligan show him playing right-handed. (The bass in the background is mirrored too.) Can someone please un-mirror this image? TenPoundHammer (talk) 10:37, 15 June 2024 (UTC)[reply]

@TenPoundHammer: I added it to Category:Images to be flopped back for you.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:26, 15 June 2024 (UTC)[reply]