Commons:Village pump - Wikimedia Commons (original) (raw)
| 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. |
December 19
Abzeronow has noted that several sister projects have decided to treat File:Flag of the Syrian revolution.svg, not the existing File:Flag of Syria.svg, as the current flag of Syria. The following are all in agreement, either by discussion or simply by content change:
English Wikipedia: en:Talk:Syria#RfC: Flag? closed as B, Syrian revolutionary flag and en:Flag of Syria shows it.
French Wikipedia: fr:Drapeau de la Syrie.
Arabic Wikipedia: ar: علم_سوريا
German Wikipedia: de:Flagge Syriens
Italian Wikipedia: it:Bandiera della Siria
Spanish Wikipedia: es:Bandera de Siria
Russian Wikipedia: ru:Флаг Сирии
Abzeronow originally proposed one solution for Commons, but Rudolph Buch has suggested several alternatives, and I have a different idea of my own, and I want to make sure we have at least a strong consensus before moving files. Proposals C, D, and E all come from Rudolph Buch; I've done my best not to alter any of his meaning but you can check [1] to verify that. Keep in mind that due to templating, there are many templates on various wikis that will necessarily use File:Flag of Syria.svg.
A) (Abzeronow's original proposal): File:Flag of Syria.svg should be moved to File:Flag of the United Arab Republic (1958–1971), Flag of Syria (1980–2024).svg and File:Flag of the Syrian revolution.svg should be moved to File:Flag of Syria.svg.
B) (Jmabel's variant on that): as in proposal A, the current content of File:Flag of Syria.svg should be moved to File:Flag of the United Arab Republic (1958–1971), Flag of Syria (1980–2024).svg. Unlike proposal A, File:Flag of Syria.svg should then become a redirect to File:Flag of the Syrian revolution.svg (rather than vice versa). This has the advantage that if the new state settles on a different flag, all we have to do is change a redirect (and possibly upload a new flag if they were to adopt something brand new).
C) Do nothing and to trust the wiki editors in updating their pages.
D) Rename File:Flag of Syria.svg to File:Flag of Syria (1980).svg without leaving a redirect. This will lead to a huge amount of broken image links (which is bad) but prompt the editors to check what flag is right for the respective page (which is good).
E) let a bot replace File:Flag of Syria.svg by File:Flag of the Syrian revolution.svg at all wiki pages. [If I understand correctly, this means to bot-edit all of the sister projects, rather than change anything at Commons. @Rudolph Buch, please let me know if that is not what you meant.]
I believe the following remark from Rudolph Buch sums up his objection to proposal A (and presumably to proposal B): "Would that automatically feed the new flag into ~500 Wikipedia pages regardless of context and caption? Like when File:Flag of Syria.svg is now used to illustrate that this is the flag that was adopted in 1980 and after the move it shows the 2024 flag without hint in the page history or any other warning to the Wikipedia editors?" User:The Squirrel Conspiracy replied to that (in part), "Correct. However the projects have backed themselves into a weird corner because there's also templates that - instead of asking for an image - automatically pull the file with the name "Flag of [country name].svg" - and those would have the wrong image if we don't move it."
Jmabel ! talk 01:06, 19 December 2024 (UTC)[reply]
Further thought: in both proposal A and proposal B, if we allow "Move and replace" to take place when we move File:Flag of Syria.svg to Flag of the United Arab Republic (1958–1971), Flag of Syria (1980–2024).svg, that will change all explicit uses of File:Flag of Syria.svg in sister projects to use the new name, which will show up in the relevant page histories, watchlists, etc. It will not affect those pages where a template generates "[[:File:Flag of Syria.svg]]. In contrast, proposal E is likely to change exactly the uses that specifically meant this particular flag, while not solving the issue for template uses, and proposal D will break all the template usages. So 'my own "ranked choices" would be B, A, C, while definitely opposing D or E. - Jmabel ! talk 01:28, 19 December 2024 (UTC)[reply]
I'd be fine with B if we know it won't break any templates so for me I'd favor A or B* (*providing it doesn't break templates) over C. I also would oppose D because it breaks pages and would be out of harmony with variants (which is why I proposed the name I did, it stays in harmony with variants). I also would oppose E since it could break templates. Abzeronow (talk) 17:15, 19 December 2024 (UTC)[reply]
I am for A or B, and oppose E. On Swedish Wikipedia, most of the intentional uses of the old flag are now linked to Flag of the United Arab Republic (1958–1971), Flag of Syria (1980–2024) (stars variant 2).svg, and if links to File:Flag of Syria.svg gives the new flag, not much more needs to be done. JohanahoJ (talk) 11:29, 22 December 2024 (UTC)[reply]
A or B sounds best. איז「Ysa」 • For love letters and other notes 14:36, 22 December 2024 (UTC)[reply]
I am going with "B". Abzeronow, the original proposer says he is fine with it. I think it works best. No one else seems to be saying Rudolph Buch's approaches are better. - Jmabel ! talk 18:23, 22 December 2024 (UTC)[reply]
Made the moves, but the "replaces" apparently did not work as I wished. It looks like there were a lot of uses of things like {{Flag entry|Width=200|Image=Flag of Syria.svg|Caption=Syria}} even for things that were about a specific year. Not a great choice. I think there is a ton of hand work to do, no matter what.
I'll do my best to take this on, starting with Commons itself, then en-wiki. If someone wants to help on some other wiki, please say so here and have at it. - Jmabel ! talk 18:39, 22 December 2024 (UTC)[reply]
@Abzeronow: are you sure about that Commons Delinker command you just gave? I'm going through these by hand, and seeing some I don't think should be changed, although admittedly the bulk of them should. - Jmabel ! talk 20:03, 22 December 2024 (UTC)[reply]
@Jmabel: If you want me to remove the command, I will (since I'm willing to let the redirect stay). Abzeronow (talk) 20:12, 22 December 2024 (UTC)[reply]
I think it probably should be removed. I'm finding it runs about 60% should change, 20% certainly shouldn't, and an awful lot of tricky judgment calls where I am trying to leave messages for more appropriate people to decide. - Jmabel ! talk 20:19, 22 December 2024 (UTC)[reply]
@Abzeronow: I'm finding more and more that should not change. Yes, we should definitely remove the command. In fact, since you said you are OK with that, I'll do it. - Jmabel ! talk 20:23, 22 December 2024 (UTC)[reply]
OK, I removed mine after you had removed yours. Abzeronow (talk) 20:30, 22 December 2024 (UTC)[reply]
Now that I have a larger sample: at the early time of my remark above, I just happened to hit a bunch that should change. I've looked at maybe 1500 pages now, and less than a hundred specifically wanted the Assad-era flag. So (1) this is overwhelmingly correct as it is and (2) there is still going to be a lot of hand-correction in a lot of wikis, way more than I personally can do. - Jmabel ! talk 22:37, 22 December 2024 (UTC)[reply]
I have left this note at en-wiki. Similar notes on other wikis would be useful. ar-wiki would be a priority, and I don't read, write, or speak Arabic. - Jmabel ! talk 23:45, 22 December 2024 (UTC)[reply]
@Mohammed Qays: regarding ar-wiki since they could help with this there. Abzeronow (talk) 02:30, 23 December 2024 (UTC)[reply]
@Abzeronow I'm ready to help, In the Arabic Wikipedia[2], there is a discussion on the subject and I will write a note about it. Mohammed Qays 🗣 19:55, 23 December 2024 (UTC)[reply]
My edit has just been reverted without discussion. I have contacted User:Ericliu1912 who did this (he is an admin on zh-wiki, but not here on Commons). - Jmabel ! talk 05:01, 24 December 2024 (UTC)[reply]
I'm not opposed to the proposal itself (in fact I do support it!), but the point is we should first clean up old usage of the flag, and then change the redirects, since this is a national flag widely used on all wikis. The issue was brought to me by members of the local community finding lots of articles showing historically erroneous Syria flags, which could not be instantly changed at once, and need time or outside assistance (e.g. global replace tool) for doing so. —— **Eric Liu（Talk**） 05:07, 24 December 2024 (UTC)[reply]
@Ericliu1912: Based on my experience so far in cleaning up several hundred of these in en-wiki, it is going to be very hard to identify what needs to be cleaned up if we don't make the change first. How do you propose to identify the places that are affected? - Jmabel ! talk 05:11, 24 December 2024 (UTC)[reply]
@Jmabel: If a consensus has been reached, I suggest we update Template:Country data Syria in every wikis first, adding a 1980 variant to the templates. —— **Eric Liu（Talk**） 05:15, 24 December 2024 (UTC)[reply]
And is it possible to have a one-time global replace done, replacing all non-Country data usage of "File:Flag_of_Syria.svg" with "File:Flag_of_Syria_(1980–2024).svg"? I guess that would ultimately do the job. —— **Eric Liu（Talk**） 05:18, 24 December 2024 (UTC)[reply]
@Ericliu1912: No, that would definitely not do the job. It's a long story, some of which is above. I want to give you this quick reply now, because explaining in detail will take 15+ minutes. I'll write out the more complicated picture and then post that. - Jmabel ! talk 05:27, 24 December 2024 (UTC)[reply]
@Ericliu1912: one other quick thought before I start that: any idea how we get word out that the template needs to be changed to handle this? - Jmabel ! talk 05:31, 24 December 2024 (UTC)[reply]
I guess it is appropriate that we leave notes to the communities using Country data Syria templates on their Village Pump respectly. —— **Eric Liu（Talk**） 05:39, 24 December 2024 (UTC)[reply]
But I wonder why it'd not work? As all direct (non-Country data) global usage of "File:Flag_of_Syria.svg" currently were indeed just "File:Flag_of_Syria_(1980–2024).svg", the replacement should mostly be smooth and sufficient. Even is it not enough in some cases like certain template wrap usage, we could still go ahead and replace most of the current links first, that should also decrease the burden for the remaining manual changes. —— **Eric Liu（Talk**） 05:41, 24 December 2024 (UTC)[reply]
@Ericliu1912: Why a global search-and-replace is a bad idea here (and also almost impossible to do in an effective manner):
- Many—I strongly suspect most—of the places where the Syrian flag is used should switch to the new flag. The following is a representative set of examples, though certainly not exhaustive.
- All geographical articles should be using the current flag, not the flag of a prior regime.
- There are presumably a lot of templates in Category:Templates related to Syria that use a flag. Those should all use the current flag, not the flag of a prior regime.
- Any infoboxes related to geography that contain a flag should all use the current flag, not the flag of a prior regime.
- As far as I'm aware, the new government of Syria, presuming it is widely recognized, which appears to be happening, will inherit (or already has inherited) all of Syria's positions in international organizations, e.g. the UN and its various affliates, the organization of non-aligned states, status as a signatory of various treaties unless the new government were to renounce those. All of those should update to the current flag.
- If you think about how flag files are used, search-and-replace is very tricky. They are almost never used in a syntax that writes out File:Flag of Syria.svg in the wikitext. For example, there are templates that effectively do File:Flag of [COUNTRY].svg, or that get at these other ways. If that's not clear, I'll elaborate; I'm trying to get you a response quickly, so I'm not approaching this at essay length.
Also: when the template is updated, if there is anything that should permanently use the current revolutionary flag regardless of future regime changes, there should be a way to specify that, too. Let's not get caught in the same thing again! (en-wiki has already done this.) - Jmabel ! talk 05:50, 24 December 2024 (UTC)[reply]
I understand the difficulties, so I suggest that we at least (1) replace direct file links and update about ~110 Country data Syria templates (which is the most obvious and widely-used template), adding a "1980" alias for them (and maybe an "opposition/revolution" alias too, just in cases which do "permanently use the current revolutionary flag"); (2) list the rest of the templates that indeed embed File:Flag of Syria.svg (in a historical context) and try to do the replacement; (3) regretfully ignore the rest like File:Flag of [COUNTRY].svg you mentioned above and change the redirect to the opposition flag, at the same time also notifying the communites, reminding them to finish rest of the work. —— **Eric Liu（Talk**） 06:05, 24 December 2024 (UTC)[reply]
@Ericliu1912: In my experience (mainly Commons and en-wiki) there is very little correlation between how the file was used (in a technical sense) and why it was used (to refer to a regime or a country). I think each wiki is going to have to work out for itself what is right for how usage is shaped on that wiki. No matter how we do this, there is going to be a LOT of hand-work, because neither case ("it meant the country" or "it meant the regime") is clearly dominant. This isn't going to be an 80-20 case, it's more in the range of 60-40. My personal guess is that more cases mean country than regime, but (on en-wiki, at least, which I'm guessing is typical of the Wikipedias in this respect) it's not dramatically more.
The more a given Wikipedia covers events relative to how much it covers geography, the more often it will mean a regime. But right now it is totally jumbled together.
This suggests a large area in which we have not at all future-proofed (for the hundreds of other countries in the world). Wikipedia wasn't around in 1989-1992, or we would have recognized this as a potentially major issue up front when we designed flag-related templates. - Jmabel ! talk 06:16, 24 December 2024 (UTC)[reply]
Which is to say, among other things: be cautious about replacing direct file links, they might have either meaning. - Jmabel ! talk 06:18, 24 December 2024 (UTC)[reply]
We certainly agree on the need to update the Country data Syria templates, though. - Jmabel ! talk 06:20, 24 December 2024 (UTC)[reply]
I've done my best to update Template:Country data Syria here on Commons (also to add some redirects that it incorrectly presumed would exist). It would be greatly appreciated if someone would check my work. - Jmabel ! talk 06:37, 24 December 2024 (UTC)[reply]
I believe I've successfully gotten the word out to the English, Spanish and Romanian Wikipedias, and I presume Ericliu1912 is driving this on the Chinese Wikipedia, but does anyone have a way to spread the word more broadly? - Jmabel ! talk 02:32, 25 December 2024 (UTC)[reply]
Please note the discussion at Commons:Deletion requests/File:Flag of Syria (2024).svg. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:26, 25 December 2024 (UTC)[reply]
but sooner or later we should change the redirect after doing requests in the others Wikipedias. Currently the situation is not normal. Because for lots of templates we have still the old flag when he is not used in a political context. In some cases, we could change the flag manually, but in others no. Panam2014 (talk) 10:46, 10 January 2025 (UTC)[reply]
Getting word out to sister projects
Again: is there some way to get word out to a large number of the sister projects? - Jmabel ! talk 02:48, 28 December 2024 (UTC)[reply]
This went stale and was archived; I've brought it back, because this still needs to reach a resolution. - Jmabel ! talk 06:25, 4 January 2025 (UTC)[reply]
The only way I can think of is the central notice, but I can not imagine WMF agreeing to this. Ymblanter (talk) 19:09, 4 January 2025 (UTC)[reply]
So what do we do? At some point we clearly need to have File:Flag of Syria.svg redirect to the current flag of Syria, and if we can't inform other wikis in advance, someone is going to feel blindsided, just like zh-wiki appears to have felt first time around. - Jmabel ! talk 00:43, 6 January 2025 (UTC)[reply]
What about Global Message Delivery via the MassMessage function? This seems to have a lower threshold than Central Notice, as it just writes a message in the village pumps of all local wikis and doesn´t include banners. (Sorry if this is a dumb suggestion, I´m not savy with technical things). Rudolph Buch (talk) 02:02, 6 January 2025 (UTC)[reply]
Is someone going to pick up the ball here, or are we just going to wait a month or two and then have a crisis when someone makes the appropriate redirect of File:Flag of Syria.svg? I've put about 16 hours into this (mostly on en-wiki, some of it here on Commons, and on es-wiki and ro-wiki). I feel that is more than my share. - Jmabel ! talk 18:15, 9 January 2025 (UTC)[reply]
January 02
On File:CDGexpSchema.jpg, this message appeared "There is a discrepancy of 1815 meters between the above coordinates and the ones stored at SDC (49°0′36″N 2°32′53″E, precision: 11 m). Please reconcile them."
On this file the coodinates are the terminal of a train, perhaps the bot refers to the airport itself. How to reconcile that ? --Io Herodotus (talk) 20:19, 2 January 2025 (UTC)[reply]
Both should use a point roughly at the centre of the line. SDC has separate properties for the coordinates of the end points. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:55, 2 January 2025 (UTC)[reply]
I'm not sure if I understand you. What line are you talking about ? At the moment there is no link between this file and the airport. Io Herodotus (talk) 23:04, 2 January 2025 (UTC)[reply]
@Io Herodotus: The railway line. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:07, 12 January 2025 (UTC)[reply]
We are talking about a railway line and an airport. I choose the terminal of the railway line which is different from the SDC of the airport. Anyway the SDC has been removed. Io Herodotus (talk) 21:23, 12 January 2025 (UTC)[reply]
Revert the bot, it should come back and fix the SDC. In principle, there is interface for fixing the coordinates in SDC manually, but I did not figure out how to use it, for me the "save" button is not clickable. Reverting the bot is easier. Ymblanter (talk) 12:45, 3 January 2025 (UTC)[reply]
Apparently this bot is looking for airport data? Why and how is it doing this? Io Herodotus (talk) 14:14, 3 January 2025 (UTC)[reply]
To be honest, I do not understand which data the boot took. @Schlurcher and Multichill: can one of you explain this to us please? Ymblanter (talk) 16:11, 3 January 2025 (UTC)[reply]
A map with a camera location????
- Where is the photographer standing? -> {{Location}} -> coordinates of the point of view (P1259)
- Coordinates of the object of the photo? -> {{Object location}} -> coordinates of depicted place (P9149)
@Ymblanter: In this case the map seems to be using {{Location}} which seems quite incorrect. Multichill (talk) 21:20, 3 January 2025 (UTC)[reply]
I see, thanks. Ymblanter (talk) 21:35, 3 January 2025 (UTC)[reply]
Updating the coordinates manually in the Structured Data tab works for me, but depends on the internet browser: Firefox no, Edge yes. Has not been fixed for a very long time now... --HyperGaruda (talk) 11:19, 4 January 2025 (UTC)[reply]
I have indeed Firefox. Ymblanter (talk) 19:08, 4 January 2025 (UTC)[reply]
January 03
Per a comment at phab:, I have created Commons:Very large files to upload (COM:2UPLOAD, COM:VLF) to keep a running list of files that could be uploaded here were it not for technical limitations on file sizes. I did search ahead of time but did not see any other such list. Pardon me if I duplicated efforts. Thanks. —Justin (koavf)❤T☮C☺M☯ 08:02, 3 January 2025 (UTC)[reply]
I don't think storing such large files for mundane things where resolution is not important even if it wasn't mundane makes much sense. Thus, I already oppose the large file-size of those videos without being merged and think their size should be reduced and people asked to upload smaller-sized videos for such things where the current file-size limit now seems more reasonable seeing what people would upload if the limit was larger. I'm not referring to the "The Black Watch" film but the other files linked on that page. Prototyperspective (talk) 09:58, 3 January 2025 (UTC)[reply]
Agreed. Especially for files like File:CSD Hamburg 2022 001 part 1 of 26.webm - the solution for these video files is to downscale them to a more reasonable resolution and upload that. Hardware which can play back and display 8k (at ~140 Mbps!) video is essentially nonexistent, and Wikimedia's video transcoding services would probably choke on a single file of that size. (As it stands, some of these segments consumed over 24 hours of CPU time to transcode to other formats - for less than five minutes of video which isn't even referenced from any content pages.) Omphalographer (talk) 23:32, 3 January 2025 (UTC)[reply]
140 Mbps for 8K is actually rather low (Video cameras can take 8K with 400 Mbps, 600 Mbps or more), and there are many hardware products which are able to play files with these bitrates (I tested back in 2019 with an RTX 2080; the bitrate alone is not enough; it also plays a role what type of chroma subsampling, bit-depth, frame rate, color space and more it uses (4:0:0 or 4:4:4)). Furthermore, I assume that the device that captured in 8K is not able to catch that much details 8K would be able to --PantheraLeo1359531 😺 (talk) 19:25, 4 January 2025 (UTC)[reply]
What I mean is that almost nobody has an 8K display to watch it on - even if you have a 4K monitor and you're viewing this video full screen (which, realistically, most users won't do), it's still being scaled down by 50%. Omphalographer (talk) 21:52, 4 January 2025 (UTC)[reply]
Not necessarily. The internal resolution can be set to be 8K, and an original 8K video is played as such (so the whole bitstream must be decoded), but only screen output itself would be in 4K. The rendering process is not smaller --PantheraLeo1359531 😺 (talk) 13:01, 5 January 2025 (UTC)[reply]
I don't see the point of uploading 8K for news type videos. I could find it useful for content where we can zoom in (i.e. scientific, etc.), but a street parade? Yann (talk) 17:35, 5 January 2025 (UTC)[reply]
It has the same utility as uncompressed TIFF images or WAV audio that has frequencies that literally can't be heard. 8K video is not really useful for my purposes, but if someone is projecting a video on the side of a building, that's handy. If we think the content of a piece of media is valid, then the highest quality of that file seems obviously useful to me, particularly since the servers create downgraded versions of thumbnails and videos that can be used in cases where extremely high quality is not needed. —Justin (koavf)❤T☮C☺M☯ 17:52, 5 January 2025 (UTC)[reply]
I think using modern codecs like AV01 could reduce 8K videos a lot in filesize and preserving the higher quality, but it could take some time until this is mainstream procedure --PantheraLeo1359531 😺 (talk) 16:27, 6 January 2025 (UTC)[reply]
There aren't that many TIFF images on here to begin with. It would be interesting to see how many of those files are even being used anywhere, or at least how many are being used in a way that can't be done just as well with a JPEG image. If I we're to guess TIFF is a fairly niche format that's hardly utilized by anyone looking for images on Commons. I can't even get them to load properly half the time myself. But I don't really see the point in having 8k videos on here if TIFF files aren't even loadable or being used by anyone at this point. There should at least be support of, and valid uses for, basic image formats on here before supporting high definition videos. Otherwise it's just putting the horse before the cart. --Adamant1 (talk) 06:28, 9 January 2025 (UTC)[reply]
January 05
On the German-language Wikipedia there arfe two files (de:Datei:Boskop-Schädel.jpg and de:Datei:Boskop-Schädel (2).jpg) which the German page says should be checked before transfer. However, they were published in the US before 1918 and should therefore be free. But commons file importer does not want to do this, saying "This file cannot be imported to Wikimedia Commons because it is marked as Vorlage:NoCommons." Joostik (talk) 11:44, 5 January 2025 (UTC)[reply]
@Joostik: Good to know that the file importer works as designed. Why are you stating that here? Or do you have a question? Questions usually end with a question mark.
Oh great, a grammar nazi ... Joostik (talk) 13:40, 8 January 2025 (UTC)[reply]
The date of publication is 1918 so well before the URAA date (1930 now) and author died more than 70 years ago so should be ok to transfer. Multichill (talk) 12:32, 5 January 2025 (UTC)[reply]
@Gerbil: You tagged each file {{Bild-PD-alt}} using de:Vorlage:Bild-PD-alt, which indicates (translated from German): "Due to URAA problem(disk.) for the time being:", "This file may not with the policies of Wikimedia Commons.", "It should be checked individually whether it may be moved to Wikimedia Commons.", and "Do not transfer this file to Wikimedia Commons without an individual review!". Is there a more appropriate tag? — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:14, 5 January 2025 (UTC)[reply]
The license I used is specified in the rules of the German-language Wikipedia for “old works”, see: https://de.wikipedia.org/wiki/Wikipedia:Bildrechte#Alte_Werke According to German law, both drawings are in the public domain 70 years after the death of the artist. However, I am not familiar with image licenses and will therefore not make any changes. Sorry. Gerbil (talk) 15:08, 5 January 2025 (UTC)[reply]
@Gerbil: Thanks. Perhaps other users of German Wikipedia will weigh in. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 23:01, 5 January 2025 (UTC)[reply]
I have transferred both files to Wikimedia Commons, same file names. You have to tweak the license tag at de.wp first (using the parameter Commons=Ja) to be able to do this. --Rosenzweig τ 04:55, 6 January 2025 (UTC)[reply]
Thank you for that! I actually tried to modify the license tag, but could not because it did not show up when clicking on "modify". Joostik (talk) 13:39, 8 January 2025 (UTC)[reply]
January 07
I have a few audio files that I liked. How do I save them as a playlist under my account, without needing to download them to my computer and setup playlist locally? Gryllida (talk) 22:32, 7 January 2025 (UTC)[reply]
I am not aware that the repository Commons offer such a capability. Is is not Spotify or YouTube, which are dedicated streaming services - a repository is more akin to a warehouse and not comparable to a radio station. Regards, Grand-Duc (talk) 22:38, 7 January 2025 (UTC)[reply]
You can create a Wikiradio playlist. Prototyperspective (talk) 19:32, 8 January 2025 (UTC)[reply]
@Gryllida: It's not ideal but you can create a personal gallery in your user space with links to the files and organize it as a playlist. The files should be playable directory in the gallery without having to open them individually in separate browser windows or something. --Adamant1 (talk) 22:11, 8 January 2025 (UTC)[reply]
Another question: how can I download multiple files from search results? Gryllida (talk) 07:45, 14 January 2025 (UTC)[reply]
January 08
This is a French electric train of the Nord region (TER Nord-Pas-de-Calais logo), but I cant place the station. I looks very similar to Brussel South station (the modern westside with a roof, but this cant be it.Smiley.toerist (talk) 11:24, 8 January 2025 (UTC)[reply]
Is it possible that back then the TER network had trains running all the way into Belgium, meaning this is really a French train in Brussels? --HyperGaruda (talk) 22:13, 10 January 2025 (UTC)[reply]
Very unlikely as this would have been big news in railhobby circles. Technicaly it is also a problem. These French trains run on 25 kV alternate current, While in Brussels it is 3000 V direct current. There are no known international bicurrent versions. The train control systems are also very different. Theoreticaly it could be an exposition or transfer train, not under its own power.Smiley.toerist (talk) 13:48, 13 January 2025 (UTC)[reply]
Hi, Recently {{PD-AR-Photo}} was changed and the old translations are no longer valid. Can a Spanish speaker go to Template:PD-AR-Photo/i18n and help translate this template. Previous version which likely can be altered to match the current English text can be found at Template:PD-AR-Photo/es. Thanks in advance. Jarekt (talk) 18:34, 8 January 2025 (UTC)[reply]
January 09
Hello, I was looking at the page User_talk:Xeroporcellio, and I noticed three images they uploaded have been deleted. I noticed this after believing that File:Armadillidium atticum mating.jpg was a copyright violation, because it's marked as 'Own work' by Xeroporcellio but in fact is also on iNaturalist by the user agapakisgeorgios under a CC BY-NC license. However, I got in touch with agapakisgeorgios, who confirmed: "Xeroporcellio is the username I have in various forums. As a result, all these photos are uploaded by myself and there is no need for flagging." They further elaborated that I could link them to this account on their user page (I have done so) and that "I had in mind that they are both by default CC BY 4.0, but now I see that iNaturalist uses CC BY-NC 4.0." Thus, while 100% understandable, I believe these removals were done in error and that, if possible, these three images should be reinstated. These are truly this user's own work and were only licensed off-site under a noncommercial license by accident. A link to a screenshot of our conversation (this image will expire after three days) can be found here as verification. TheTechnician27 (Talk page) 05:44, 9 January 2025 (UTC)[reply]
@TheTechnician27: Commons:Undeletion requests. Otherwise you can ask a random admin. Doing an undeletion request is probably the better way to go about it though. --Adamant1 (talk) 06:31, 9 January 2025 (UTC)[reply]
And I would recommend that you copy that PNG to somewhere it won't disappear after three days. - Jmabel ! talk 18:08, 9 January 2025 (UTC)[reply]
I started a deletion request for Template:Double MetaCat a while ago at Commons:Deletion requests/Template:Double MetaCat and there seemed to be enough support to delete it at the time. @Bastique: subsequently decided to close the DR as keep because the template is involved in so many things and I supposedly didn't layout a clear enough way to deal with it.
There's many reasons why the template is clearly problematic though. Just to a name a few, it's placing a bunch of categories in Category:Countries by city by country that have nothing to do with "countries by city by country" for unclear reasons. Not to mention the whole idea of a category system based on "countries by country" is totally nonsensical to begin with. The same goes for similar categories that it's using like Category:Countries by color by country. There's also Category:Countries by city by year, which it seems to be populating with subcategories for states by year for some reason. It also populates non-exiting categories like Category:Buildings by function by condition for reasons that don't really make sense either.
Anyway, the template is clearly a problem. But I guess it can't be deleted without a clear way to do so and I'm not seeing a way to do it without a lot of work and creating a bunch of red links. The template is extremely complicated and the original creator doesn't seem to know how to fix it themselves. So I'm wondering what other options exist for dealing with it outside of just letting it continue causing issues. So is there someone on here who can rewrite the template to fix things or does anyone have another idea about how to deal with it? Adamant1 (talk) 07:34, 9 January 2025 (UTC)[reply]
Yes, that template certainly looks more complicated than it needs to be. If we're going to keep it, it would be good to remove some of the functionality.
If we want to eliminate the template, maybe the effort could start by identifying the categories where the template causes problems and replacing the template with hardcoded things. Some of these cases might use {{AutoDMC}}. Category:AutoDMC double meta categories even has a note that says that template might give "wrong or garbage parameters to" to {{DMC}}. To me, that says that the template isn't ready to be used. Maybe we could start cleanup efforts with use of the auto template. -- Auntof6 (talk) 10:59, 9 January 2025 (UTC)[reply]
Stepping back a bit, I think part of the problem here isn't just {{DMC}} itself, but also that most of the categories it's used in tend to fall into a couple of common, frequently overlapping, patterns:
- "YEAR by SOMETHING by month", e.g. Category:2006 by topic by month
- "SUBJECT by SOMETHING by topic", e.g. Category:Canada by year by topic
- "SUBJECT by SOMETHING by TIME", e.g. Category:Canada by month by year
- "SUBJECT by topic by SOMETHING", e.g. Category:Canada by topic by year
This all feels like we're slicing the same files into dozens of different categories based on different combinations of properties it has. There's got to be some better way to handle this without this explosion of categories - the fact that DMC is needed at all is a symptom. Omphalographer (talk) 00:01, 10 January 2025 (UTC)[reply]
I don't disagree with that. From what can tell all of these categories are multiple subcats deep before you get to anything meaningful. So at the end of the day most, if not all, of the top level categories as well as the subcats are meaningless trivia that aren't actually useful beyond being created by the template for whatever reason. Its questionable a lot of these categories would be created or retained to begin with if not for the template. I'm not sure how to deal with it outside of getting rid of template though. Since I think it will just recreate the categories. There's really no consensus to not have an explosion of categories either. People seem to be perfectly fine with this this type obtuse nonsense in general. So I'm not really sure how to deal with it outside of getting rid of the template and then fixing whatever issues that might cause afterwords. Its a screwed up situation without a simple solution either way though. I thought about doing a couple of thousand CfDs for every subcat but that's clearly a non-starter lol. --Adamant1 (talk) 00:32, 10 January 2025 (UTC)[reply]
Just a question. When we look at the duplicate or redundant file deletion policy, here and here, it's said that the file must not be in use, and any existing usages can be replaced by the new file if the project’s policies are met. The best quality file is always the one to be preserved, but, what about the quality of the information in the file's pages? What if the file with lower resolution is the one with the best description page? The thing is even more serious for duplicates, since they can be speedy deleted. Very useful information about the file can be lost if a good description is replaced by a worse one. The problem is even worse if one of the files has poor references to the author, the source, its license, is missing an attribution or license review template, etc, since this could cause to eventually lose both versions of the file. Yes, I'm doing my paranoid job again, but it's also a needed job :-). Maybe before deletion of duplicate and redundant files, the administrator always carefully reviews the file page (and its history) and takes care to move the missing parts to the page of the file that is to remain, but perhaps some improvement would be convenient here. MGeog2022 (talk) 13:59, 9 January 2025 (UTC)[reply]
When I do a redirect like this, I always try to merge relevant Commons metadata first. That is certainly what I recommend, but not everyone is that careful. - Jmabel ! talk 18:11, 9 January 2025 (UTC)[reply]
@Jmabel, thanks for taking care of it. That sounds like something should probably be done to improve this. A policy to focus attention on that when this type of deletion is performed would be good. But the main issue here is to avoid losing publicly visible history. That is, if, for example, a vandal removes content of a description, that old content remains publicly accessible to power users who view the history, and could be easily restored even years later. When a file is deleted, all its history is gone from public view. Categorization and license information may be gone. Could the history of a file deleted as a duplicate or redundant be kept visible as a kind of “parallel history” from the file that is kept? I think this is highly convenient: deletion of duplicate and reduntant files should be more of a "merge" than a true deletion. Could this functionality be asked to WMF? MGeog2022 (talk) 19:07, 9 January 2025 (UTC)[reply]
Or at least a clear notice of the type "this file once had a duplicate/redundant file under the name XYZ. Don't delete it as copyvio before checking the deleted duplicate file first", to make sure that a file with full attribution and license information cannot be lost due to a silly thing like someone uploading a slightly higher quality version, but not paying attention to those details, and that “increase in quality” resulting in the destruction of the file. I think it is very unfortunate that this could happen without being able to prevent it. MGeog2022 (talk) 19:21, 9 January 2025 (UTC)[reply]
@MGeog2022: I think it is very rare that anything like that arises. Do you have even two examples of where you think that might have happened? - Jmabel ! talk 19:27, 9 January 2025 (UTC)[reply]
@Jmabel, I don't have even one, but better to be safe than sorry. I'm not thinking about bad things that necessarily happened, but that the current operating mode allows to happen. Certainly we have very good things in place to prevent problems, but more can always be done. User 1 converts a SVG or PDF to PNG (the SVG or PDF is never uploaded to Commons). User 2 converts it to WebP, with less size and more quality, but doesn't cite source (for example, the typical case of selecting "own work" when it isn't). The PNG is deemed redundant and is deleted. Then, the WebP is nominated for deletion as "copyvio - not own work". That's a formidable way to potentially destroy a file that we were considering very safe to remain here. MGeog2022 (talk) 19:42, 9 January 2025 (UTC)[reply]
This concern is far from hypothetical. I've seen multiple cases where good metadata was carelessly discarded in the deletion of a duplicate file. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:15, 12 January 2025 (UTC)[reply]
@Pigsonthewing, @Jmabel, at least, I think the point "If there are varying descriptions in the different image description pages, ensure all the relevant information is merged into the copy to be preserved" should also be included in the official policy for redundant files, not only duplicates, to ensure that it is always an official policy not to be breached. But I maintain that history of the "merged" (removed) duplicate or redundant files should remain visible. I'd have made a proposal for this, but, from past experiences, I have very low faith that it would succeed. MGeog2022 (talk) 13:32, 13 January 2025 (UTC)[reply]
Well, trying to comfort me with what we have, PNG and JPEG files have very different purposes, and any good file in one of those formats is usually very unlikely to be replaced by one in the other. Any file taken at full resolution from the original source, will never be replaced by another better one in the same format. When reading the deletion policy, I had some kind of WebP paranoia, because it's a format that allows smaller files than both PNG and JPEG, with the same quality (it allows both lossy and lossless compression), but WebP files, at least for the moment, seem to be a very rarely chosen option in Commons (0.0339% of files). Even if they become more widespread, having a smaller WebP file with the same content as an existing PNG or JPEG, probably won't be enough to delete a years old file only because of that, and the file deemed to be redundant would be the newer, WebP file. MGeog2022 (talk) 14:35, 13 January 2025 (UTC)[reply]
After reading the title of this section, I thought it was about loosing the EXIF, XMP, IPTC metadata of a file. But reading through the section, this does not even seem to be considered at all. --C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 17:34, 13 January 2025 (UTC)[reply]
From our good friends at the Public Domain Review: https://pdimagearchive.org/ —Justin (koavf)❤T☮C☺M☯ 14:28, 9 January 2025 (UTC)[reply]
Well, good luck to them, but they claim "10,046 out-of-copyright works" We have more PD works from the UK alone. Do they have anything we don't? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:21, 12 January 2025 (UTC)[reply]
The games have begun. In advance of the ground invasion, the softening up of the landscape is currently underway. By this I mean the de-legitimisation of Greenland as a constituent country of Denmark. The excuse is that Greenland is not a part of Denmark, it's a part of the Kingdom of Denmark. I noticed it first at Category:Churches in Greenland. No doubt further sapping is taking place elsewhere. Predictably, the discussion with the editor (@Hjart: ) got nowhere. Can someone say "Stop!" please? Laurel Lodged (talk) 15:43, 9 January 2025 (UTC)[reply]
I'm not sure if I understand the reasoning here: Greenland being a constituent country in the larger Kingdom of Denmark and co-equal to metropolitan Denmark is more legitimate (or whatever) than Greenland just being a part of Denmark. —Justin (koavf)❤T☮C☺M☯ 16:01, 9 January 2025 (UTC)[reply]
Technically, you're correct. But practically speaking, it would be a nightmare to implement. Every category of Denmark would have to have a parallel category for Kingdom of Denmark. Massive duplication for no practical benefit. To most readers, they would not understand the difference. The same would then have to be done for the Kingdom of the Netherlands and others. At the very least, it merits a discussion, not unilateral action that smacks of vandalism or POV-pushing. Laurel Lodged (talk) 16:21, 9 January 2025 (UTC)[reply]
Denmark and Kingdom of Denmark definitely needs to be split. Another reason is that Faeroe and Greenland are no members of the EU but making them part of Denmark and not the Kingdom of Denmark makes them part of the EU. The category tree Category:Kingdom of Denmark already exists. GPSLeo (talk) 17:12, 9 January 2025 (UTC)[reply]
That's all true. But who's going to do the work of creating many thousands or near-duplicate categories? Simply unilaterally breaking the parentage by deleting Denmark from all Greenland categories is not a solution; it's closer to vandalism IMHO. Laurel Lodged (talk) 18:00, 9 January 2025 (UTC)[reply]
Why do you think that this affects many thousand categories? This change only affects the higher level categories which are at most 2000 for a depth of 3. GPSLeo (talk) 20:16, 9 January 2025 (UTC)[reply]
Thanks to @MB-one: for fixing Category:Churches in the Kingdom of Denmark. One down, 1999 to go. Laurel Lodged (talk) 16:03, 10 January 2025 (UTC)[reply]
Hi, I noticed by chance that some files I uploaded some years ago accidentally has my personal name in their meta data. I'm not very comfortable with that, and I cannot see that it actually adds anything of importance to the file, so I am wondering if it is possible to somehow change or remove this information? I've been trying to find the answer already by searching on my own but couldn't find an answer, but apologies beforehand if I am cluttering this forum with already well-known issues. Thanks beforehand anyway, Yakikaki (talk) 16:42, 9 January 2025 (UTC)[reply]
upload it to imgur and download and then upload here. very easy to do it and higher resolution compared to other solutions. @Yakikaki modern_primat ඞඞඞ ----TALK 17:06, 9 January 2025 (UTC)[reply]
☝️that was about removing, if you just remove your name or camera model you can do it on your OS. for example win 10. just check specifications and do it. i dont know too much about that so i suggest you to research about this solution. + with this way no loss for resolution. modern_primat ඞඞඞ ----TALK 17:08, 9 January 2025 (UTC)[reply]
@Yakikaki: Assuming it's a JPEG file and you're looking at the "Metadata" section on the image page, what you need to do is to upload a new version of the file with the Exif data suitably modified. See Commons:Exif for a list of potentially useful editing tools. Once you've uploaded the new version, you can ask for the old one to be deleted. Commons:Revision deletion might be relevant, but I'd just go for sticking a speedy deletion template at the top with a clear note that you only want the old version deleted. Something like {{[SD](/wiki/Template:SD "Template:SD")|G7|Please delete ONLY the oldest version, which has inappropriate personal information in the metadata}}. If the data are so private that you don't want to draw attention like that, you might want to contact the Commons:Oversighters instead. --bjh21 (talk) 17:20, 9 January 2025 (UTC)[reply]
Or if you have anything like a working relationship with some admin, provide that admin with a list of the files that need this.
You give no indication here whether this is, like, a dozen files or hundreds. If it's only a dozen or so, feel free to email me the list once you've uploaded the versions without the problematic metadata. - Jmabel ! talk 18:18, 9 January 2025 (UTC)[reply]
Thanks a lot, I'll do that. It's just a few files. Yakikaki (talk) 20:38, 9 January 2025 (UTC)[reply]
Flagging this discussion on enwiki about some reporting by The Forward, with a leaked Powerpoint, indicating that the Heritage Foundation (a US-based conservative organization) plans to "identify and target" -- i.e., out/dox -- wiki editors active in certain political topics. (I'm sure you can guess which ones, this isn't meant to be a political discussion but an opsec one.)
The relevance to Commons is that some of those plans including cross-referencing usernames across platforms, and running facial recognition software against people's photos. Given that we host many meetup photos as well as photos of users, and other associated data, this is a potential ticking time bomb of a security risk.
Granted I have no idea what a concrete actionable solution here is -- besides adding any malicious/IP-grabbing links to the spam blacklist -- but I wanted to bring it to people's attention, maybe someone reading this could be affected, maybe someone can think of something I can't. Gnomingstuff (talk) 17:10, 9 January 2025 (UTC)[reply]
I don't currently participate at en.wp but I am willing to help editors on any other WMF wiki who for some reason may want to post sensitive information or are afraid of being a target of these reactionary chuds. I welcome their hatred. —Justin (koavf)❤T☮C☺M☯ 18:23, 9 January 2025 (UTC)[reply]
I think the main message for now is that it is good that we are very careful with granting bureaucrat, checkuser and oversight rights. With the technical fingerprinting mentioned we might need to block known external domains from being linked. GPSLeo (talk) 19:35, 9 January 2025 (UTC)[reply]
If I was the heritage fooundation, I would start by downloading the MW archive at dumps.wikimedia.org. Therefore I see no point in blocking IPs. This may actually be counter productive. Wikipedia is written with a cc-by-sa license and this license says you are not allowed to use technical barriers to block people from downloading the licensed content. Doing it never the less would open a way to the Heritage foundation to sue WMF to get access to the information.
Starting from 20th the new president or his DOGE watchdog can effectivly force the WMF to give US government bureaucrat, checkuser and oversight rights. AFAIK US law allows this to be done in secret.
WMF could stop to record the IP numbers of people editing MW and they can move the WMF out of the US, but otherwise the identity of people editing MW (at least in the US but probably everywhere in five eyes territory) must be considered known to friends of US government. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 17:48, 13 January 2025 (UTC)[reply]
No, the president is limited in what they can force WMF to do. See McIntyre v. Ohio Elections Comm'n, 514 U.S. 334 (1995) ("The freedom to publish anonymously is protected by the First Amendment, and, as Talley indicates, extends beyond the literary realm to the advocacy of political causes.") and NAACP v. Alabama (1958) ("We hold that the immunity from state scrutiny of membership lists which the Association claims on behalf of its members is here so related to the right of the members to pursue their lawful private interests privately and to associate freely with others in so doing as to come within the protection of the Fourteenth Amendment.") And the WMF will have the ACLU and EFF aggressively on their side. I have a hard time believing that this would push this button right off the top; courts are not going to be thrilled with such a hostile intrusion into privacy of random Americans.--Prosfilaes (talk) 04:09, 14 January 2025 (UTC)[reply]
Not just Americans, I think. They could collect data from non-American wiki editors, and, if they are really hostile, forward the data to non-democratic regimes. Imagine they'd send data about Saudi Arabian editors to the Saudi Arabian state: those wiki editors might end up in prison because of the heritage foundation (or face even more severe consequences for editing wikis). Nakonana (talk) 16:08, 14 January 2025 (UTC)[reply]
The oldest television programme on the BBC's iPlayer (possibly not available outside the UK, at least without a VPN) is First-year Flashbacks, a compilation of clips marking the anniversary of the resumption of transmissions after WWII.
Some questions:
- Can we determine which clips - if not the whole programme - are no longer in copyright in the UK?
- Would that include the sound, or just images?
- When does the content fall out of copyright in the US?
- Do we have someone with the video chops (not my forte!) to edit them into stand alone files? At the very least, the modern intro would need to be removed.
I'm happy to assist with metadata and descriptions, if someone can do the latter. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:07, 9 January 2025 (UTC)[reply]
Out of copyright in the UK is complex; COM:UK is life+70, and the best I can find for film is Copyright law of the European Union: "For films and other audiovisual works, the 70-year period applies from the last death among the following people, whether or not they are considered to be authors of the work by the national law of the Member State: the principal director (who is always considered to be an author of the audiovisual work), the author of the screenplay, the author of the dialogue and the composer of music specifically created for use in the cinematographic or audiovisual work." That would include the whole video.
Out of copyright in the US is also complex, but for different reasons. It's 95 years from publication, and transmission is not publication. If they weren't first published before 2002, they could be life+70. Clearest form of publication would be by sale of physical copies, on 35mm, VHS, or DVD. CopyrightData lists several cases where broadcast programs were deemed not to be published, so I don't know what would exactly be publication before sale of actual copies.--Prosfilaes (talk) 22:33, 11 January 2025 (UTC)[reply]
I started a CfD on this topic here. Considering the scope of the discussion (it would affect more than 300 subcats), and the fact that previous discussions on this topic went stale, I'd like to draw a bit more attention to it. ReneeWrites (talk) 21:00, 9 January 2025 (UTC)[reply]
Was there a recent update to the Upload Wizard? Starting this morning or last night, when I try to upload a batch of files, it takes me through the upload and rights steps as expected, but the describe step only includes one file. I've tried this with different size batches and different photos. Mentioning this issue on Discord, it sounds like I may not be the only one affected? — Rhododendrites talk | 21:37, 9 January 2025 (UTC)[reply]
I too am having difficulties with Upload Wizard. After filling out the first page (including adding a specific public-domain tag) the process does not continue to the next page. Instead a moving stripe pattern is added to the field I filled out to add a specific public-domain tag. It goes no further. This has happened today on both an iPhone and Windows computer, Safari and Chrome. Jacqke (talk) 02:49, 10 January 2025 (UTC)[reply]
Pinging @Sannita (WMF). - Jmabel ! talk 02:54, 10 January 2025 (UTC)[reply]
Yes, I already mentioned it at Commons:Upload Wizard feedback --PantheraLeo1359531 😺 (talk) 11:34, 10 January 2025 (UTC)[reply]
@Rhododendrites @Jacqke Hi, thanks for reporting. No, AFAIK we didn't do any change to UploadWizard in the last three weeks, due to code freeze for the holidays. There is one patch incoming on the known bug about missing information about error, but again AFAIK it has not been merged yet, and should go up next week. Can you please open a bug on Phabricator and put me as a subscriber? Let me know. Sannita (WMF) (talk) 15:41, 10 January 2025 (UTC)[reply]
I have also encountered the same bug as @Rhododendrites, filed it as phab:T383508. And the custom license tags issue is already at phab:T383415 (although perhaps they have the same underlying cause). the wub "?!" 00:23, 12 January 2025 (UTC)[reply]
I am still unable to load using the Wizard, from Chrome on Windows and on iOS 17.5. Still having the "Add a specific public domain tag" field filled with stripe pattern. Jacqke (talk) 00:51, 12 January 2025 (UTC)[reply]
When I switched to "author has been dead for 70 years", it advanced to the next page. Jacqke (talk) 00:55, 12 January 2025 (UTC)[reply]
Found that removing the "Description" field from the Exif data allowed me to upload multiple files at once again. the wub "?!" 12:15, 12 January 2025 (UTC)[reply]
January 10
Hi, I have found this strange category — Category:Old men wearing vests — which seems to be dedicated for photos of Modi. I'm no expert but I feel like this should contain other examples to be useful? Given that it is for one person I feel like it is redundant and could be deleted Carlinmack (talk) 14:16, 10 January 2025 (UTC)[reply]
January 11
One user nominated the photos without explaining what rules they were breaking, I told him they what they were, he didn't respond, and now they get deleted? I don't understand this. The pictures were valid. There are hundreds of variations of the flags which are allowed on here, such as this one. But no, an altered hammer and sickle to be viewable from the size of a flagicon in an infobox is unacceptable. You for Me and Me for You (talk) 19:37, 11 January 2025 (UTC)[reply]
@You for Me and Me for You: the nominator referred to the "rules they were breaking" as "Out of scope". A courtesy link to Commons:Scope would have probably come in handy. Fictional flags (except notable/famous ones) tend to be seen as non-educational, hence probably the deletion. --HyperGaruda (talk) 21:48, 11 January 2025 (UTC)[reply]
Okay, but the Soviet flag was useful. You for Me and Me for You (talk) 22:41, 11 January 2025 (UTC)[reply]
@You for Me and Me for You: Then please see COM:REFUND. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:28, 12 January 2025 (UTC)[reply]
January 12
Hello.
The upload form doesn't allow upload multiple files.
Please repair this bug.
Thanks.
--ComputerHotline (talk) 07:34, 12 January 2025 (UTC)[reply]
It's a known bug, see this topic and this page. ReneeWrites (talk) 10:13, 12 January 2025 (UTC)[reply]
Is Category:St Marylebone Cemetery the same cemetery as Category:East Finchley Cemetery? On OSM as far as I can tell, all the photos of the former (which is East Finchley Cemetery (Q1277838)) are located in the latter (which doesn't have a Wikidata item). Is St Marylebone Cemetery a part of East Finchley Cemetery, or is it an older/alternative name for the same place? Sam Wilson 12:55, 12 January 2025 (UTC)[reply]
de:East Finchley Cemetery and en:East Finchley Cemetery suggest that it is the same cemetery, opened in 1854/1855 as St Marylebone Cemetery, and that the name was changed to East Finchley Cemetery in 1965. --Rosenzweig τ 19:43, 12 January 2025 (UTC)[reply]
@Rosenzweig: Thanks! I'm not sure why I didn't go and check the Wikipedia articles. :-) I'll merge them to Category:East Finchley Cemetery. Sam Wilson 22:45, 12 January 2025 (UTC)[reply]
Why are categories like Category:1936-01-28 hidden? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:35, 12 January 2025 (UTC)[reply]
Probably because of this change. At least I guess so. --Rosenzweig τ 19:39, 12 January 2025 (UTC)[reply]
Thank you. I know how they are hidden; my question was why. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:03, 12 January 2025 (UTC)[reply]
@Pigsonthewing: I added the hiddencat template to be consistent with Template:Photographs taken on navbox and Template:Country photographs taken on. There has been some discussion (and edit warring) about the hiddencat in the past in the first template, you can find a bit more about that in the template's edit history and on the talk page. A number of comments reference an even older discussion, but I don't know when or where that one was held. ReneeWrites (talk) 23:31, 12 January 2025 (UTC)[reply]
Why on earth do you think the day categories need to be consistent with those templates? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:29, 13 January 2025 (UTC)[reply]
They're all templates that pertain to dates down to the specific day, one for each country and one for pictures that have a date but not a location. These were already hidden, so it made sense for me for the parent category to be hidden as well. ReneeWrites (talk) 17:35, 13 January 2025 (UTC)[reply]
I don't agree. I don't agree that the categories emitted by the templates need to be hidden. Nor does the (scant) discussion you referred to show any consensus that they need to be hidden. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:40, 13 January 2025 (UTC)[reply]
I was here to explain my reasoning. I saw a bunch of templates that do roughly the same thing, two of them were hidden, one was not, so I made the third one hidden too. I didn't make the original decision and I'm not here to argue about that. If you feel so strongly that the hiddencat should be removed then you can just do that.
I'm also not going to continue this conversation. You've taken on a condescending tone from the jump for no discernible reason. ReneeWrites (talk) 19:01, 13 January 2025 (UTC)[reply]
I think it should be undone. —Justin (koavf)❤T☮C☺M☯ 18:56, 13 January 2025 (UTC)[reply]
I concur. Date-categories have little to do with "photographs-by-date" categories.
Dates are used to categorize all sorts of events besides "I took a photo at that time": Dates are used to document festivals, demonstrations, battles, treaties, elections... I still hope that we will eventually use them to sort newspapers that were published on given dates.
Hiding these categories will make people think that nobody should categorize stuff by dates. --Enyavar (talk) 08:19, 14 January 2025 (UTC)[reply]
I have reverted the edit. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:23, 14 January 2025 (UTC)[reply]
I'm wondering why this file can't be imported from de.wiki to commons. It is a photo of an ancient coin, which was published in 1903 (122 years ago) in a book by George Hill, who died in 1948 (77 years ago). But when I try to use the "import to commons" function, the import is denied. Furius (talk) 16:57, 12 January 2025 (UTC)[reply]
You'll have to tweak the license template a bit to be able to transfer it to Commons. I've transferred the file to Commons, same file name. --Rosenzweig τ 17:19, 12 January 2025 (UTC)[reply]
Do we have a guide for people who want to scan and upload books, on how to do the former, well? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:06, 12 January 2025 (UTC)[reply]
Hi Pigsonthewing, we have Help:Scanning and Help:Converting. --Ratekreel (talk) 10:39, 13 January 2025 (UTC)[reply]
Useful but well hidden; thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:30, 13 January 2025 (UTC)[reply]
January 13
Am I the only one who hates having to spell out the date when a photo was taken when I upload it? Whose idea was this? We got on perfectly well without it, and I've been here 18 years. Sardaka (talk) 10:23, 13 January 2025 (UTC)[reply]
A lot of modern digital photographs will have the time and date in the metadata, in which case the date is already filled in when you upload it to Commons. ReneeWrites (talk) 10:42, 13 January 2025 (UTC)[reply]
There's also a calendar picker, so the date does not need to be "spelled out". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:32, 13 January 2025 (UTC)[reply]
Your earliest upload, in October 2007, included the "spelled out" date (indeed, it did so twice, the second time completely unnecessarily). So "We got on perfectly well without it" seems to be false. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:35, 13 January 2025 (UTC)[reply]
What is the distinction between Category:Decorative plates and Category:Plates? Is the former for plates that are purely decorative, or is it intended to include plates that are decorated, but serve a function as tableware? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:42, 13 January 2025 (UTC)[reply]
That's the impression I get based on the Wikidata infobox, etc.: a plate is a general device and decorative plates are a subset of them. —Justin (koavf)❤T☮C☺M☯ 21:05, 13 January 2025 (UTC)[reply]
I asked "Is it A or B", you sad "yes". I can't make sense of that. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:08, 13 January 2025 (UTC)[reply]
Excuse me: I misread what you wrote. I believe that "decorative plates" are ones that are purely decorative and not fit for use as serving plates. I do not believe they are plates which may be used for serving food. —Justin (koavf)❤T☮C☺M☯ 21:13, 13 January 2025 (UTC)[reply]
I agree with Koavf about the intent of the categories, except that of course almost any plate can be used for serving, so the line isn't totally clear. If it's old enough, even a lead-based glaze isn't proof it was never intended for serving.
Often, but not always, decorative plates are made with a protrusion on the back with a pair of small holes to hold a wire or string for the specific purpose of attaching the plate to a wall. - Jmabel ! talk 02:54, 14 January 2025 (UTC)[reply]
January 14
- Category:Censored by lack of FOP (better change "FOP" to "FoP" here).
- Category:Blacked out versions of images relying on FoP (currently a subcategory of the above, yet its subcategories contain censored images that are not blacked out)
- Category:Gaussian blurs to avoid copyright infringement (which contains both censoring FoP objects and non-FoP objects like posters, advertisements, and more)
I suggest major harmonization of the categories that related to censoring or blurring of copyrighted works in public spaces (due to no-FoP rules of those countries), since categorizations are becoming inconsistent. My proposal:
- Abolish "blacked-out versions" category and its subcat's and merge with "censored by lack of FoP", since blacking out is essentially censoring landmarks.
- Merge all "blacked-out" subcategories to censored (e.g. Category:Censored by lack of FOP in the Philippines).
- Suggest adding a subcategory under "Gaussian blurs", fittingly named "Category:Gaussian blurs by lack of FoP" or something similar, and let's decide if we want to split it by subcategories by country (like, Category:Gaussian blurs by lack of FoP in Romania as a subcategory of Category:Censored by lack of FoP in Romania).
Some discussion is needed. JWilz12345 (Talk|Contributions) 03:41, 14 January 2025 (UTC)[reply]
I don't think it's necessary or useful to have separate categories for different styles of redaction (blacking-out, blurring, pixelation, cropping, strategically placed fingers, etc). The redaction isn't the subject of the image; the specific techniques used are entirely incidental to the image.
Having country-specific subcategories for FoP redactions is potentially useful for advocacy reasons. But let's not overdo it; these are basically maintenance categories, so we shouldn't be spending too much time setting up or maintaining them. Omphalographer (talk) 05:37, 14 January 2025 (UTC)[reply]
@Omphalographer perhaps limit to two categories per censored image (if the method used is blurring)? For example, one for Category:Censored by lack of FoP in Romania and the other for Category:Gaussian blurs by lack of FoP. No coutry-specific subcategories under Gaussian blur by lack of FoP to avoid overdoing and potential COM:SCOPE issues. We already have Category:Images with Gaussian blurs in Japan, though. JWilz12345 (Talk|Contributions) 06:01, 14 January 2025 (UTC)[reply]
Or, since countries like Germany and China have FoP, but we have images of blurred/blacked-out images from these countries, suggest to rename "Censored by lack of FoP" to "Censored versions of images relying on FoP" (and "Censored versions of images relying on FoP in Germany/in China/in France et cetera). Then, abolish category instances of "blacked-out versions of images...". JWilz12345 (Talk|Contributions) 06:10, 14 January 2025 (UTC)[reply]
I'm hoping someone can fix this as I don't know how to. The largest file size (1994x3200) for this Anna Karenina title page has a broken link that prevents the file from loading. The correct file link is https://upload.wikimedia.org/wikipedia/commons/thumb/c/c7/AnnaKareninaTitle.jpg/1994px-AnnaKareninaTitle.jpg
--ThePinkShoes (talk) 22:13, 14 January 2025 (UTC)[reply]
Good evening. On October 20th I created the category "Category:Church of Nuestra Sinyora de l'Asumpción, Peralta d'Alcofea" (actually Category:Iglesia de Nuestra Señora de la Asunción, Peralta de Alcofea) linked to article an:Ilesia de Nuestra Sinyora de l'Asumpción de Peralta d'Alcofeya, which does not exist in any other project. Today the name has been changed to Spanish "Category:Iglesia de Nuestra Señora de la Asunción, Peralta de Alcofea" (with advocating error included already solved) and when asking the author of the change the reason I have received inappropriate answers. I ask here for an explanation of the reason for changing the name of the category of an Aragonese church with an article only in the Aragonese Biquipedia to a name in Spanish. Greetings, RenatoGar (talk) 22:39, 14 January 2025 (UTC) P.S.: Given what has happened, this consultation will be my last contribution to Commons. RenatoGar (talk) 22:48, 14 January 2025 (UTC)[reply]
No particular opinion other than that it is completely irrelevant to Commons which language Wikipedias currently have an article. - Jmabel ! talk 04:15, 15 January 2025 (UTC)[reply]
Now I understand why there are calls from Aragonese speakers on Twitter to boycott Wikimedia projects. Of course, I will never contribute to Commons, where I see my language being persecuted and blocked. It is clear that there is hatred against my language here. RenatoGar (talk) 08:25, 15 January 2025 (UTC)[reply]
January 15
For File:Bucharest - 9 Strada Colței storefronts.jpg I was looking for (and failing to find) a category about printing photographs on ceramics. I'm guessing it would belong somewhere under Category:Photographic processes, but looking at the categories there I can't readily find even an appropriate place to add such a thing. - Jmabel ! talk 04:27, 15 January 2025 (UTC)[reply]
Given that in Central Europe this is something of an industry, I'm really surprised not to find anything. - Jmabel ! talk 04:27, 15 January 2025 (UTC)[reply]
Paper9oll's 2,218 × 2,160 still
My 1,103 × 1,080 attempt to capture the same
(I raised a thread at the help desk for this last week, but only got a couple of short responses and realise that this may have been the wrong forum for it.)
I recently flagged many of User:Paper9oll's uploaded YouTube video stills as looking to me like obvious AI upscales, but in a subsequent discussion on their talk page they said that they were simply downloading the original videos and capturing frames from them, and don't believe the images to be upscaled, or agree with me that they even look upscaled, and don't know what else to say.
An example upload is shown. To the left is the image Paper9oll uploaded, to the right is my own attempt to capture the same still from the same video.
Paper9oll's image is twice the resolution (larger even than the highest resolution of the original video that YouTube will serve me) and does seem to show clear signs of AI upscaling which aren't discernable in the original. In general, the face has a much higher resolution than her hand and clothes, which are about the same in each image - this is typical of AI upscalers like MyHeritage that are designed for use on portrait photos. Across the subject's forehead, individual hairs are visible (with an unusual pinstripe pattern on the rest of the hair), but below the level of her chin the hair instantly drops to the same low resolution blur as in my image.
Would other users agree that these look AI upscaled, and should be flagged as such? (Such a decision is significant because it means that the images couldn't be used on the English Wikipedia.) My best faith assumption is that Paper9oll is obliviously using some software that's automatically upscaling the extracted stills. Belbury (talk) 09:39, 15 January 2025 (UTC)[reply]
This is 100% upscaled with AI. If the image was an ultra-high resolution still of the original video, it would be consistently sharp across the board, but it isn't. The eyes, eye wrinkles. lips and strands of hair are incredibly sharp but details outside of that specific area turn wobbly. The right eye of the upscaled image looks in a slightly different direction, and has a slightly different color from the original. ReneeWrites (talk) 10:15, 15 January 2025 (UTC)[reply]