Commons:Village pump

From Wikimedia Commons, the free media repository
(Redirected from Commons:Village Pump)
Jump to navigation Jump to search

Shortcut: COM:VP

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
🌐 Village pumps for other languages
COMMONS DISCUSSION PAGES
Welcome to the Village pump

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

Please note:

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

Purposes which do not meet the scope of this page:

Search archives:

   

Start a new discussion

# 💭 Title 💬 👥 🙋 Last editor 🕒 (UTC)
1 Die Gartenlaube: Adding an artist to an image within Wikidata 12 3 Broichmore 2024-07-31 11:21
2 >600 TB of recent media files 25 8 MGeog2022 2024-08-04 15:07
3 Self-talken photo 13 7 Jeff G. 2024-08-04 10:43
4 Category:Videos by language 6 3 RZuo 2024-07-31 10:59
5 Are 4K videos discouraged now? 20 12 Miguel Angel Omaña Rojas 2024-08-04 20:34
6 Library of Congress # 3 3 Geohakkeri 2024-07-31 08:18
7 Nudity category 1 1 RZuo 2024-07-31 12:02
8 Meet with the Structured Content team at Wikimania! 1 1 Sannita (WMF) 2024-08-01 14:38
9 Commons Gazette 2024-08 1 1 RZuo 2024-08-01 22:12
10 2024 Summer Olympics logo.svg 3 3 Abzeronow 2024-08-03 21:04
11 Should we convert all TIFFs to JPEGs? 32 22 Gestumblindi 2024-08-05 12:32
12 Semi-protection on the Village Pump? 11 7 Yilku1 2024-08-07 18:51
13 Acceptability of file names containing emoji 14 7 Jmabel 2024-08-05 21:11
14 Further dissemination of Wikimedia Commons Atlas of the World needed 23 5 JopkeB 2024-08-07 14:29
15 Santo Domingo de Guzmán 5 3 Jmabel 2024-08-07 19:18
16 Talk pages of deletion requests – again 9 5 Matrix 2024-08-07 08:45
17 Nearcoord and SDC 5 4 Jmabel 2024-08-07 19:19
18 File:Leo K Thorsness.jpg 4 2 Jeff G. 2024-08-07 00:36
19 Reminder! Vote closing soon to fill vacancies of the first U4C 1 1 Keegan (WMF) 2024-08-06 15:29
20 Image file seems broken 4 3 Glrx 2024-08-07 04:06
21 Nominating for both speedy and community revue deletion has a problem 1 1 Richard Arthur Norton (1958- ) 2024-08-07 01:20
22 New type of tram in Częstochowa 1 1 Smiley.toerist 2024-08-07 11:58
23 Category:Files that need updating 3 3 Omphalographer 2024-08-07 17:45
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.
Women at the well, India, early 20th century. [add]
Centralized discussion
See also: Village pump/Proposals   ■ Archive
Template: View   ■ Discuss    ■ Edit   ■ Watch
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days.

July 26

[edit]

>600 TB of recent media files

[edit]

The amount of data on Commons (most recent file versions) surpassed 600 Terabytes (ca. 546 TiB) recently. --PantheraLeo1359531 😺 (talk) 08:11, 26 July 2024 (UTC)[reply]

Special:MediaStatistics for verification --PantheraLeo1359531 😺 (talk) 08:12, 26 July 2024 (UTC)[reply]
Are there any reliable offline backups of the data, by the way? I think I have read somewhere that Commons data is stored on two servers or something like that, but do we have a backup that could be used if some large-scale corruption of data happened? It wouldn't take much, really: For 600 TB, about 20 LTO Ultrium 8 tapes with a capacity of 30 TB each would suffice. And such tapes could be safely stored in different places. Gestumblindi (talk) 16:54, 27 July 2024 (UTC)[reply]
@Gestumblindi We're a distribution service, so recovery and restores can be crowdsourced for less than the cost of your tapes Elizium23 (talk) 03:21, 28 July 2024 (UTC)[reply]
lmao, sure. Good luck with that project. —TheDJ (talk • contribs) 08:11, 28 July 2024 (UTC)[reply]
I'd be extremely surprised if the WMF didn't have backups of all their websites. --Adamant1 (talk) 08:14, 28 July 2024 (UTC)[reply]
1. It’s more than 600tib, because this doesn’t count old and deleted versions. The same system also contains all the OTHER wikis files, so we can add that as well
2. Wikimedia Commons and wmf didn't have media backups between 2005 and 2022 (and up to 2012 there wasnt even a second server), but they finally exist.
3. As far as I know, there isn’t a public copy right now, because the deleted images would have to be filtered out. But im not 100% sure, i cant find details about it atm. —TheDJ (talk • contribs) 08:32, 28 July 2024 (UTC)[reply]
It's to bad there's no way to easily create backups of specific folders on here because it would be cool if there were backups of the more important ones on somewhere like archive.org or a similar website. --Adamant1 (talk) 08:44, 28 July 2024 (UTC)[reply]
You probably read about it here I think which has more info and proposes (an) additional backup(s): Commons:Requests for comment/Technical needs survey/Media dumps.
I think it would be great if people could come to WMF with some large hard drives and get a subsection copied on them such as all files that are in use in any Wikimedia project or all files except for >1 GB video files and a large .tiff files folder.
And I don't think the amount of data by file-size is a good measure of success, e.g. there are a lot of 4K videos of the same unnotable boring event that don't get watched at at all taking up lots of storage space or many duplicate large files and so on. Instead, there probably should be greater focus on the large gaps there are, such as various specific illustrations for concepts where illustrations would be very useful. I kind of doubt there were no backups until 2022 or would consider a second server a backup. More offline backups would be good and a good way for that would be to better enable third parties to copy over things, which is also useful for many other applications. Prototyperspective (talk) 10:34, 28 July 2024 (UTC)[reply]
Backups are very crucial, and I was surprised that there were not any until 2022, also because only backupping files should not be so expensive, as they only need to be stored on several disks. --PantheraLeo1359531 😺 (talk) 10:41, 28 July 2024 (UTC)[reply]
Maybe there is a chance to establish some sort of decentral service (like Mastodon), where every instance gets maybe 10-20 TB, so files are stored in many different areas of the world, so complete data loss in one point of the world becomes more unprobable --PantheraLeo1359531 😺 (talk) 10:43, 28 July 2024 (UTC)[reply]
Maybe there could or should be some central place – like Commons:Backup or Help:Backup and/or Commons:Media dumps or a Commons WikiProject – where things like those in this thread can be discussed over longer term, people can organize or collaborate and ask questions, and there is some WMC-specific info on backups similar to wikitech:Media storage/Backups. Maybe you and @MGeog2022: could set it up and aggregate+organize all the info on this subject in one place. Prototyperspective (talk) 11:32, 28 July 2024 (UTC)[reply]
I can understand why they wouldn't want to provide a full backup of everything on their servers to the public but there really should be publicly available backups of the files that we can already access because they clearly aren't copyrighted. If nothing else just for our own purposes. There's lots of situations where I could see something like that being useful outside of just having it available if the servers ever go down. Plus like why not? Everything is already there, organized, just needs to be mass downloaded, put in zip file, and reuploaded to archive.org. Does anyone if there's an easy way to download everything in specific folders? I'm tempted to do it myself but I have no clue how to. --Adamant1 (talk) 12:17, 28 July 2024 (UTC)[reply]
600 TB or 1 PB are peanuts to the Internet Archive, as they store over 200 PB of data :) --PantheraLeo1359531 😺 (talk) 13:09, 29 July 2024 (UTC)[reply]
One does not simply just download and then upload 600 TB over the internet. At these sizes you would probably transfer via physical hard disks being handed over to someone in person. Bawolff (talk) 08:35, 30 July 2024 (UTC)[reply]
Obviously. That's why I said there shoulfd be a way download specific folders. Most of the stuff on here probably comes from Flickr anyway. So there's no reason to back it up. --Adamant1 (talk) 09:12, 30 July 2024 (UTC)[reply]
@Prototyperspective, sorry I wasn't around here last days. Yes, it would be fine to have a page with such information in Commons itself, I can create it at some moment over the next days. I agree with @Adamant1in both things: there's no reason (besides the needed technical work) not to allow mass downloading of freely licensed media files, and not all media in Commons has the same level of quality an importance, but it can be very difficult to identify all the important ones. Dumps don't need to be only one 600 TB file (in fact, much smaller Wikipedia dumps are composed of lots of files).
@Gestumblindi, yes, there are now full Commons backups in 2 datacenters. Backups were never better than they are now, and the vast majority of files were never lost over many years, but things can and should be improved even more (more copies, more places, publicly downloadable dumps). MGeog2022 (talk) 14:21, 1 August 2024 (UTC)[reply]
@Prototyperspective, @PantheraLeo1359531, I created the page Commons:Dumps and backups. MGeog2022 (talk) 13:50, 4 August 2024 (UTC)[reply]
Thank you :) --PantheraLeo1359531 😺 (talk) 14:43, 4 August 2024 (UTC)[reply]
You're welcome! Now we have all that information in Commons, without the need to collect it from here and there at Wikitech and Phabricator. MGeog2022 (talk) 15:07, 4 August 2024 (UTC)[reply]
I think the best way, if we're talking about a backup as a precaution against catastrophic data loss, is still a backup on media physically separated from any live system such as the large-capacity LTO Ultrium tapes I mentioned, which can be safely stored in different locations. Only if you have your data on tapes (or maybe large harddisks) in a vault, you can rest assured that the media / data will survive even some catastrophic large-scale event that affects whole swathes of the internet and possibly people's online / "cloud" backups as well. Gestumblindi (talk) 16:55, 29 July 2024 (UTC)[reply]
Just to clarify - the files were stored on several (geographically separated) disks prior to the 2022 point. Its not like they were on a single computer where a single disk failing would have caused the files to be lost. Generally for backup you want more than just mirroring across multiple disks - ideally you want it disconnected from the system and stored off site, so for example if the system was hacked the hacker couldn't just issue a command to delete all the files or some sort of natural disaster can't just take out the whole data center. I'm not exactly sure what the wmf backup strategy is, but my understanding is that is the part that only came into place in 2022. Bawolff (talk) 08:32, 30 July 2024 (UTC)[reply]
@PantheraLeo1359531, when I learned that there were no backups before 2021 or 2022, I was very surprised too. Fortunately, I became aware of it (and I started contributing to Commons) when there were already backups in place, so the scare was not so bad :-). But it's scary to think in what danger were all images and videos we saw in Wikipedia and other wikis. Before 2021-2022, there were (as there are now) multiple (more than just 2) copies of each media file in both main datacenters (each one stored in RAID disks), but that couldn't be called as true backups. MGeog2022 (talk) 17:01, 1 August 2024 (UTC)[reply]
Of course, a backup is absolutely needed! But now it's there :). I always have local backups of my files I contribute here, but many maybe don't, and when we take into account that some images may be out of reach to collect again, it could be a huge loss. But now we can be more relaxed :D --PantheraLeo1359531 😺 (talk) 17:06, 1 August 2024 (UTC)[reply]
+1, better safe than sorry :) --PantheraLeo1359531 😺 (talk) 19:00, 29 July 2024 (UTC)[reply]

Self-talken photo

[edit]

I took this photo years ago, and then noticed a wikimedia user claimed it as their own. How can I remedy this issue? I've gone on both the photo's talk page and the users talk page and have gotten no response.

Lansing Center

— Preceding unsigned comment added by Criticalthinker (talk • contribs) 10:15, 26 July 2024 (UTC)[reply]

@Criticalthinker: Hi, You uploaded your photo under the name File:10 Lansing Center.JPG to the English-language Wikipedia on 2 April 2006. The other user merely transferred it to Commons in 2011. You can correct and complete the information in the description page. An administrator on en.wikipedia should check what license you gave the file on Wikipedia. -- Asclepias (talk) 11:21, 26 July 2024 (UTC)[reply]
Licensing was {{PD-self}}, uploaded by User:Criticalthinker. I believe this is now fixed, but feel free to edit further if I didn't have it right. - Jmabel ! talk 18:33, 26 July 2024 (UTC)[reply]
Oh, wow. Thanks! Criticalthinker (talk) 07:09, 27 July 2024 (UTC)[reply]
@Criticalthinker: Just a side note, as you released the file into the public domain through "PD-self", you have relinquished your right to be named as the creator of the file. It's still a good idea to do so, so people see who has released the file and that everything is in order license-wise, but basically, anyone can now do with this file what they want without mentioning you. If you want to prevent this, you should use an attribution license like CC-BY or CC-BY-SA. That being said, it would probably still be inappropriate for any other person to claim that they're the author, but as others pointed out, that's not what happened here. Gestumblindi (talk) 16:49, 27 July 2024 (UTC)[reply]
Okay, so this wasn't "fixed." What do I do? I've been on Wiki for awhile, but I have no idea of the process you've spoken of. What do I need to do, specifically? Criticalthinker (talk) 00:12, 28 July 2024 (UTC)[reply]
You start uploading your photographs under the Creative Commons Attribution-Share Alike 4.0 license. Thats what you do now Trade (talk) 03:44, 28 July 2024 (UTC)[reply]
For this specific image and any images that you may have uploaded as "PD-self" in the past, you can't "fix" it - it means you have irreversibly released them into the public domain and people don't need to mention you as the creator. As said above, if you want to be credited, just use CC-BY or CC-BY-SA for future uploads. Gestumblindi (talk) 08:42, 28 July 2024 (UTC)[reply]
As was said, it was uploaded in 2006. I'd not even remembered that I'd uploaded it until I came across it, again, years and years later, let alone the licensing. I don't even remember what the old wiki would have looked like, then, and I don't imagine many of you do, either. The rudeness was completely unnecessary in the replies. But if that's how you're going to deal with it, thanks for absolutely nothing. Criticalthinker (talk) 06:36, 29 July 2024 (UTC)[reply]
I didn't mean to be rude, I thought I was just stating the facts for your information; if that came across as rude, I apologize. Gestumblindi (talk) 17:08, 29 July 2024 (UTC)[reply]
"it would probably still be inappropriate for any other person to claim that they're the author" Would it be against policy tho? Trade (talk) 03:45, 28 July 2024 (UTC)[reply]
That's not a helpful comment. What exactly would the uploader achieve with that? The file format wouldn't change the PD-self license. Also, I don't see the advantage from a technical point of view of converting a JPEG photo to PNG. Gestumblindi (talk) 18:43, 30 July 2024 (UTC)[reply]
@Richard Arthur Norton (1958- ): Any png image will look fuzzy when scaled down (due to design decisions discussed in phab:T192744), so you may want svg or jpg versions instead.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:43, 4 August 2024 (UTC)[reply]

July 30

[edit]

Are 4K videos discouraged now?

[edit]
Tracked in Phabricator
Task T368433

Before when I uploaded 4K videos they would be encoded and offered as a playback option. Now it only encodes up to HD and there is no option to play 4K except to play source. Example ref: File:Koayu river - summer day - 2024 July 28.webm I'm just curious if I am missing an option or doing something wrong or if something was changed in the backend? Nesnad (talk) 11:59, 30 July 2024 (UTC)[reply]

Correct. They take an enormous amount of processing power and we were getting more and more uploads. This then (multiple times) caused the transcode servers to overload to the point where all servers were tied up transcoding humongous files almost no one was watching, and never getting around to the audio files and smaller variants of the videos that are actually used. For this reason higher resolution transcodes were put on hold. This is documented in phab:T368364 and phab:T368433.
The transcode pipelines are currently being rewritten so that they can run on Wikimedia's Kubernetes platform. Once that is done, it might be easier to tweak the capacity and priority of transcoding, but that is going to take a while. —TheDJ (talk • contribs) 13:56, 31 July 2024 (UTC)[reply]
It is sensible to suspend transcoding of high resolution versions, when ressources are limited. It is also sensible to annoucnce that on site. A significant number of users ignore Phabricator completely for example because it is monolingual and many people simply do not speak or read english. C.Suthorn (@[email protected] - p7.ee/p) (talk) 15:28, 1 August 2024 (UTC)[reply]
Not prioritizing audio files and lower resolution videos before 4K is an absolutely bonkers design decision i gotta say Trade (talk) 03:48, 2 August 2024 (UTC)[reply]
As a very general rule: 4K video is usually overkill unless you're using a very good camera and some form of stabilization (e.g. a tripod or Steadicam, or optical image stabilization in the camera). This video looks like it was taken with a handheld camera, and it is not a good use case for 4K video; most of it is heavily affected by motion blur, so the 4K resolution is largely wasted. Omphalographer (talk) 00:24, 1 August 2024 (UTC)[reply]
Got to agree. 4K is super pointless with something like this. A lot of people can't even stream video at 4K to begin with anyway. --Adamant1 (talk) 03:59, 1 August 2024 (UTC)[reply]
Are we talking about the Western world Trade (talk) 15:07, 1 August 2024 (UTC)[reply]
I usually shoot in 4K when doing documentations, but only with fullframe camera that can profit from the high resolution, but there are several cases where 4K brings not more details than Full HD --PantheraLeo1359531 😺 (talk) 11:51, 2 August 2024 (UTC)[reply]
I must point out that the issue was not stabilization of handheld, it was the framerate. At least from what I can see from my computer. To your point, 4K is indeed useless if, and only if, it doesn't go with an above-than-avarage fps and bit rate. This is based on my experiments on YouTube -- should probably do more of such experiments here to back my claim. Miguel Angel Omaña Rojas (talk) 05:49, 2 August 2024 (UTC)[reply]
Wikipedia asserts that only two movies have been released on 4K Blu-Ray at 48 FPS or higher, and only a few films were shot at that speed. Most feature films are 24 FPS. 4K does need high bit rates, but FPS is irrelevant.
YouTube is not a good tool for this; there's a complex proprietary system trying to send a stream that is playable on the receiving system and maximizes quality without taking up too much expensive bandwidth. It will not replicate what will happen on Commons.--Prosfilaes (talk) 17:32, 3 August 2024 (UTC)[reply]

Good to know. I remember when people said HD was a waste because most people couldn't play it. 4K is future proofing. But I understand it was taking a lot to transcode the video. Are there plans to go back and transcode 4K video once pipelines are rewritten? Any case, thank you for the explanation guys! :) Nesnad (talk) 05:16, 1 August 2024 (UTC)[reply]

Using a higher video resolution is only "future-proofing" when there is high-resolution detail to preserve in the source video. That isn't the case here; the source video is blurred, and saving those blurry frames at a high resolution doesn't make them any less blurry. Omphalographer (talk) 05:53, 1 August 2024 (UTC)[reply]
The source video is available without limitations. Only transcoded versions with same resolution but possibly lower bitrate are not available. GPSLeo (talk) 06:07, 1 August 2024 (UTC)[reply]
This is exactly what I was talking about. It is all about the FPS numbers going along with 4K. It’s not that I’m against 4K, but when it comes to a lot of people (obviously not you) they shoot 4K in small FPS. That is what 4K is making 4K useless today. I don’t know in the future, but that whole 4K + High FPS numbers makes the files bigger, and that’s a biggie as well. Miguel Angel Omaña Rojas (talk) 22:10, 2 August 2024 (UTC)[reply]
Does framerate really matter? It's a video not a PC game Trade (talk) 04:06, 3 August 2024 (UTC)[reply]
Framerate matters for video, 30 fps can look different from 60 fps and sometimes details are not properly shown at 30. Abzeronow (talk) 21:02, 3 August 2024 (UTC)[reply]
Yes for details as @Abzeronowexplained, and also for camera movement. In a nutshell, it makes the moving imahes more real-life. Miguel Angel Omaña Rojas (talk) 20:34, 4 August 2024 (UTC)[reply]
I can bring up concerns about 4K videos at the Commons Video Meetup at Wikimania. I plan on attending the meetup in person so I'll try to remember to mention the challenges of 4K and the desire for support where appropriate. Abzeronow (talk) 00:11, 2 August 2024 (UTC)[reply]
Could you propose a way to request exceptions to the 4K "ban" for individual videos? Those in cases where the improved resolution heavily benefits. Or at the very least find a way to allow for a limited number of 4K uploads of high quality Trade (talk) 05:01, 2 August 2024 (UTC)[reply]
But no cases, where the improved resolution heavily benefits, have been presented?!? Just kill it. Alexpl (talk) 17:22, 2 August 2024 (UTC)[reply]

August 01

[edit]

Meet with the Structured Content team at Wikimania!

[edit]

Hi all! CParle (WMF) and I will be attending Wikimania 2024 in Katowice, Poland. Despite not having any presentation in the program, we wanted to let you know that, if you're attending Wikimania too, you can come meet us at all time during the conference and discuss with us about UploadWizard improvements or about the logo detection tool or just Commons issues. We'll be around during the whole conference, so from August 7 to 10, don't be shy and come to say hi! Sannita (WMF) (talk) 14:38, 1 August 2024 (UTC)[reply]

Commons Gazette 2024-08

[edit]

Currently, there are 184 sysops.

Edited by RZuo (talk).

Commons Gazette is a monthly newsletter of the latest important news about Wikimedia Commons, edited by volunteers. You can also help with editing!

--RZuo (talk) 22:12, 1 August 2024 (UTC)[reply]

August 03

[edit]

2024 Summer Olympics logo.svg

[edit]

Think we could export this to Commons as a simple logo?--Trade (talk) 04:34, 3 August 2024 (UTC)[reply]

No. I think this just meetsCOM:TOO-US via American Airlines. Glrx (talk) 14:21, 3 August 2024 (UTC)[reply]
Definitely above the ToO in France. Abzeronow (talk) 21:04, 3 August 2024 (UTC)[reply]

Should we convert all TIFFs to JPEGs?

[edit]

Following this discussion - Commons:Bots/Work requests#Convert Category:Photographs by Carol M. Highsmith to JPEG (bot request), I'm trying to assess what sort of consensus we have regarding the conversion of TIFFs to JPEGs in general. Also, see past discussion in the archive. -- DaxServer (talk) 16:36, 3 August 2024 (UTC)[reply]

Reasons to prefer JPEG over TIFF for our purposes:
  • Easier to view, download & use for people with slower internet connection
  • JPEG is generally much easier to use for average people without specialized programs/knowledge about file types
  • Often significantly smaller file size while preserving the image quality (often over 1000% smaller (sometimes over 10000% (TIF|JPG))
  • TIF has issues with displaying correctly as thumbnail
  • raw .tif files cannot be displayed in browsers (URL ending .tif (TIF example, JPG example) - this means properly zooming is not possible without downloading a large file to your PC (or even better your phone)
  • TIF is not indexed by Google and presumably other image search engines (as the format is unsuitable for web purposes, see above)
Proposed solution is to convert the TIF file to JPG and upload as such, copy all information, and make both files cross reference each other. This has been done already with ~250,000 NARA/LOC files (see e.g. here)
TheImaCow (talk) 17:05, 3 August 2024 (UTC)[reply]
All these problems are solved by the jpeg thumbnails they are available. GPSLeo (talk) 18:14, 3 August 2024 (UTC)[reply]
TIFF is the world's most featureful image format, so not all TIFFs are good candidates for conversion to JPEG. Multipage TIFFs might be converted to PDF, and non-photographic TIFFs would be better off as PNGs.--Prosfilaes (talk) 17:38, 3 August 2024 (UTC)[reply]
@Prosfilaes: Any png image will look fuzzy when scaled down (due to design decisions discussed in phab:T192744), so you may want to upload svg or jpg versions, too.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:41, 4 August 2024 (UTC)[reply]
We don't need to align 100%. Anything that goes "we do this here, so we should do it everywhere" is flawed. We shouldn't waste resources on this. Targeted approaches might make sense sometimes, but most of this material isn't even in use, nor will it ever be. —TheDJ (talk • contribs) 17:40, 3 August 2024 (UTC)[reply]
if a bot has the ability to automatically convert tiff to jpeg (upload as new file), i think obviously the sensible option is
make a template that users can use to tag files for automatic conversion. something similar to rotation requests.
because as users have explained, most tiff files are not actively in use. there's no urgency to convert them. maybe when they do become needed in future, web technology has developed to being able to display tiff properly.
so for now, if any tiff is to be used somewhere, and the user thinks it's beneficial to have a jpeg version instead, only then convert that specific tiff. otherwise most files dont need a duplicate jpeg. RZuo (talk) 12:42, 4 August 2024 (UTC)[reply]
 Oppose, original-quality and file type of the TIFF files must be maintained, especially if these were directly imported from GLAMs that various Wikimedians partnered with. If there is a need for JPEG, then upload under a new file name. We can't be sure if forced conversion of TIFFs to JPEGs may lead to discouragement of some GLAMs to continue partnering with Wikimedian volunteers. And by the way, TIFF is a lossless file type, whereas JPEG is a lossy file type. I've read somewhere above that this proposal may be of benefit for Wikipedia articles (this is solved by uploading a JPEG version under a new file name), but as per some of our voices at Commons talk:Media knowledge beyond Wikipedia, Wikimedia Commons does not only aim to be a central media repository for all Wikimedia projects like enwiki; it aims to be a reliable partner of external institutions like GLAMs and non-profit orgs for their freely-licensed media content to be hosted and reused globally. To be a reliable partner, IMO, we should not alter the original, raw TIFF files that the GLAMs donate to us; instead, it is best to convert to JPEG and upload as a new file. I can recall a template for LoC files that states raw files directly donated by LoC should not be altered in any way so that those represent the exact-quality files from LoC, and any modification/s must be uploaded as a/as new file/s. JWilz12345 (Talk|Contrib's.) 23:55, 4 August 2024 (UTC)[reply]
@JWilz12345: You seem to be opposing some proposal other than the one being made. To quote from the original post, "Proposed solution is to convert the TIF file to JPG and upload as such, copy all information, and make both files cross reference each other." Your objection seems to presume that the TIFF would be delete, but nothing of the sort is being proposed. - Jmabel ! talk 03:16, 5 August 2024 (UTC)[reply]
@Jmabel: ah, then that's better. I have striked my comment and vote. As long as the original raw TIFF files that GLAMs and other NGOs donated to us are kept intact and not deleted (whether JPEG versions as separate files are mandated), then any proposal is fine for me. The raw TIFF files should be kept in perpetuity as we are supposed to be reliable partners of various GLAMs that Wikimedians partnered for many years. JWilz12345 (Talk|Contrib's.) 03:40, 5 August 2024 (UTC)[reply]
As long the original files are not being deleted, I am not against it but. But the question is if it is necessary in every case, and some already have JPEG copies :) --PantheraLeo1359531 😺 (talk) 07:04, 5 August 2024 (UTC)[reply]
The next question is that we currently have automatic conversion from tiff to jpg for every tiffs. What benefit would manual duplication do? (cost for manual duplication is that there would be huge number of duplicate files which metadata would be needed to updated, keep in sync etc. It also multiplies the edits done to the files which user are seeing etc. --Zache (talk) 07:12, 5 August 2024 (UTC)[reply]
The only way I'd support it is if it was a de-emphasised templated link. Nothing as prominent as {{Extracted image}}, more on the lines of:
An unmodified JPEG version of this TIFF is available at File:Foo.jpg.
It really needs to be minimally disruptive. Adam Cuerden (talk) 07:38, 5 August 2024 (UTC)[reply]
  • Another comment: I spend a lot of time, as a human in the loop, adding sensible metadata to image files. Any bot'ed activity can only do this badly and vary probably contribute to at least some misleading information. RobbieIanMorrison (talk) 11:25, 5 August 2024 (UTC)[reply]
  •  Oppose TIFF is the better, lossless format, and usually, the automated JPEG thumbnail generation from TIFF works. You can download any TIFF file in various sizes as JPEG from Commons. There are some issues with the thumbnail generator, but these mean that the thumbnail generator should be fixed. I don't see a need to flood Commons with JPEG duplicates of TIFF files. Gestumblindi (talk) 12:32, 5 August 2024 (UTC)[reply]

Semi-protection on the Village Pump?

[edit]

I see that the Village Pump is now semi-protected, which strikes me as quite inappropriate. Yes, vandalism is a pain, but this is the Village Pump, where users, including new users and IPs, should be able to come to start or participate in a discussion.--Prosfilaes (talk) 17:40, 3 August 2024 (UTC)[reply]

@Prosfilaes: I think you are right about this. @A.Savin: Please reconsider. Per this log entry 13:45, 22 June 2024 (UTC), you changed protection to "Edit=Allow only autoconfirmed users" for six months. If vandalism here is such a problem, then we just need more Admins to patrol it.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 11:33, 4 August 2024 (UTC)[reply]
I recall that I had the bad idea to revert vandalism here myself .. rather than wait for an admin to do so and apply semi-protection. Agree that it could have been done for a shorter period, but most newbie questions are better on Help Desk. Maybe we should just add a notice for that. Enhancing999 (talk) 13:26, 4 August 2024 (UTC)[reply]
@Enhancing999: Some header tweaking may do the job.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:54, 4 August 2024 (UTC)[reply]
I wouldn't even call it "vandalism" here. This is not an article, but a talk page: there is nothing to vandalize. Inappropriate comments that are out of place should be removed, but they are written in his/her own name by the person who writes them: there is no visible wrong information. MGeog2022 (talk) 14:07, 4 August 2024 (UTC)[reply]
Diff. Enhancing999 (talk) 14:22, 4 August 2024 (UTC)[reply]
Certainly, sorry: I wrote too quickly. MGeog2022 (talk) 14:25, 4 August 2024 (UTC)[reply]
Perhaps new or unregistered users could be restricted to adding comments and editing their own comments, if that's possible. MGeog2022 (talk) 14:27, 4 August 2024 (UTC)[reply]
Is it possible to add page protection so only logged-in users can edit, even if the account is new? This seems like the most reasonable course of action to me as well. ReneeWrites (talk) 20:27, 4 August 2024 (UTC)[reply]
This is the new normal, instead of doing their job they'll just ban everybody from editing, like they did with overwriting files. Yilku1 (talk) 18:51, 7 August 2024 (UTC)[reply]

August 04

[edit]

Acceptability of file names containing emoji

[edit]

For instance File:Spring has arrived^^^^^ 🌼🌼🌼🌼🌼🌼 - Flickr - rossomoto.jpg. I was thinking about renaming to something without them but I don't want to waste my time on it if they aren't an issue. It seems like a super weird way to name files though. So Yes, no, or does it depend on the circumstances when it comes to file names with emoji? --Adamant1 (talk) 02:04, 4 August 2024 (UTC)[reply]

If you know specifically what the plant in the photo is, a rename to a more specific name would be in order (under criterion 2 - "meaningless or ambiguous name"). But renaming just to remove the emoji is harder to justify, especially when the filename is still meaningless without them. Omphalographer (talk) 04:02, 4 August 2024 (UTC)[reply]
@Omphalographer: Hhmmm. The Emoji seem to show up as different flowers depending on the platform. So I'm not even sure how I'd figure that out to begin with. Maybe they could just be replaced with "flowers" though since it doesn't seem to be a specific plant. --Adamant1 (talk) 04:22, 4 August 2024 (UTC)[reply]
I mean the budding flowers seen in the photo, not the ones represented by emoji in the filename. As you've astutely observed, the exact appearance of emoji is font-dependent. Omphalographer (talk) 05:13, 4 August 2024 (UTC)[reply]
The emoji is the same on every platform, but the rendering can change depending on which device/browser/etc. you view it with. ReneeWrites (talk) 07:09, 4 August 2024 (UTC)[reply]
@Adamant1: I don't think emoji are themselves objectionable in file names. Indeed in this case they're the only part of the filename that actually describes what's in the picture. They might be difficult to type, but I think we accept that people might have to copy and paste filenames that are in unfamiliar scripts. So unless there's actually some problem that they're causing, I think they can stay. --bjh21 (talk) 11:55, 4 August 2024 (UTC)[reply]
Commons:File naming advises "Avoid abusing Unicode...symbols such as "♥" are often more natural when spelled out ("heart"), also increasing visibility in search. Furthermore some characters do not render correctly at all in certain operating systems and browsers. It is a good idea to stick to letters, numbers, underscore (space), ASCII hyphen/minus/dash, plus, and period (dot), as these do not have any MediaWiki restrictions." DMacks (talk) 15:16, 4 August 2024 (UTC)[reply]
I wouldn't want to see emojis completely banned from file names -- in the most obvious case, they'd be appropriate in a file showing how a particular font renders that emoji -- but this seems like an inappropriate file name. - Jmabel ! talk 19:44, 4 August 2024 (UTC)[reply]
How is "Commons:File naming" relevant here? Enhancing999 (talk) 01:29, 5 August 2024 (UTC)[reply]
@Enhancing999 because it's about naming files? I don't understand the thrust of your question. - Jmabel ! talk 03:18, 5 August 2024 (UTC)[reply]
The question was if the filename is acceptable. Enhancing999 (talk) 03:36, 5 August 2024 (UTC)[reply]
I don't think the issue of emojis is at all addressed there; perhaps it should be. - Jmabel ! talk 04:14, 5 August 2024 (UTC)[reply]
Maybe need a new guideline that answers basic questions, such as Special:Permalink/830407356. Enhancing999 (talk) 04:19, 5 August 2024 (UTC)[reply]
Though certainly that was too tight: discouraged use of any non-Latin alphabet. - Jmabel ! talk 21:11, 5 August 2024 (UTC)[reply]

Further dissemination of Wikimedia Commons Atlas of the World needed

[edit]

I have the feeling that Wikimedia Commons Atlas of the World is barely known among Wikipedia or even Commons regular visitors. Its quality can certainly be improved, but the first step to achieve that is that it is known enough. If it was an independent project (Wikiatlas), no doubt it would be much more known and used (and improved). There's no need to create a new independent project, but I think it should be given more own character, and find a way to make Wikimedia and Commons users who are looking for maps, aware of its existence. MGeog2022 (talk) 14:17, 4 August 2024 (UTC)[reply]

Maybe it would work better as a separate project. I'm not really convinced of the usefulness of gallery namespace in general. Enhancing999 (talk) 14:25, 4 August 2024 (UTC)[reply]
Yes, but it would need a lot of WMF involvement and devote resources to it. I'm not too optimistic about it. I am convinced that there can be other ways to give it visibility.
I'm not really convinced of the usefulness of gallery namespace in general: I don't agree with that, unless gallery namespace is split in several ones, for different types of galleries. Surely there are lots of galleries that do not add anything, but others, for example, galleries about cities, allow you to see things you could not see in Wikipedia or other wikis, including the hypothetical future atlas. MGeog2022 (talk) 14:36, 4 August 2024 (UTC)[reply]
I wonder how many galleries of locations consist of less than 10 pictures all taken more than 10 years ago. This despite there being dozens of other images available. Enhancing999 (talk) 14:39, 4 August 2024 (UTC)[reply]
Many galleries about sufficiently important cities are not bad (photos being some years old does not have to be a problem):
Of course, there are also examples of not so good city galleries (perhaps the perception depends on the size and country of the cities in which one places the focus):
MGeog2022 (talk) 14:59, 4 August 2024 (UTC)[reply]
Rennes seems to be mostly more than 10 years old. 2008?
Old isn't a problem as such, but it just makes it likely that the gallery isn't representative any more.
Obviously, you could consider any image as relevant if you just want a visual list of subtopics. Enhancing999 (talk) 01:36, 5 August 2024 (UTC)[reply]
The lack of scope or a point to a lot of galleries is the main problem with them IMO. They don't really well as dump for random images of a large subject area, but then the reverse is also true if the gallery just exists to recreate a couple of images from a near empty category. So there really needs to be a clear purpose, direction, and theme for them to work. --Adamant1 (talk) 02:54, 5 August 2024 (UTC)[reply]
Old isn't a problem as such, but it just makes it likely that the gallery isn't representative any more.: to see city landmarks, perhaps any 21st Century photo is good enough. But it is a symptom that nobody cares about the gallery, and obviously this lack of interest is a very bad sign. See my comment below: what I propose for the Atlas may be a solution for other gallery pages as well. MGeog2022 (talk) 09:50, 5 August 2024 (UTC)[reply]

I have long felt that the gallery capability is potentially very valuable and tremendously underutilized. A few examples of ones I've done: Places of worship in Seattle, Romanian Orthodox churches in Bucharest, Pioneer Square Park. - Jmabel ! talk 19:47, 4 August 2024 (UTC)[reply]

I totally agree. For example, I created this gallery page to show the map sheets organized in a comprehensive way. Looking at the category to which they belong doesn't provide a good general view of the map series.
Returning to the problem with some galleries, perhaps some of them are not necessary at all, but others just need more dissemination, which is the same problem Wikimedia Commons Atlas of the World has. If there was an easy way to navigate galleries, with a clear hierarchy, things would be better. Galleries are to be seen as a means, not an end in themselves. Perhaps a solution would be that Commons main page linked some special important galleries (such as Atlas of the World, and others, let's say paintings, galleries of cities, etc), that serve as a starting point to continue navigating gallery pages. MGeog2022 (talk) 09:44, 5 August 2024 (UTC)[reply]
In Commons main page: "If you are browsing Commons for the first time, you may want to start with Featured pictures, Quality images, Valued images or Featured media.". Why not also some special root galleries? Content section below that links to some root categories, perhaps there could be more of them there, and also some important galleries that allow navigating to many other gallery pages. MGeog2022 (talk) 09:54, 5 August 2024 (UTC)[reply]
Returning to the true subject of this discussion, I think that Atlas of the World (perhaps also more galleries) should be linked from Commons main page. Can this be done? What do you think about it? MGeog2022 (talk) 08:40, 6 August 2024 (UTC)[reply]
Main_cities_of_Spain_at_MTN50_first_digital_edition can work indeed, as it doesn't need maintenance.
Similarly the 1866 map at Maps_of_France#Historical_maps.
Dynamic lists are another possibility: Streets in Fresnes (Val-de-Marne).
Even in Wikipedia articles not edited on a daily basis, it can be worth comparing the current illustrations with what's available here. Sometimes all illustrations date back from the time the article was created. Enhancing999 (talk) 10:05, 5 August 2024 (UTC)[reply]
Yes, that's a problem even with text content in Wikipedia: once the subject is well covered, not much care is taken to update it. On the other hand, this probably is a lesser problem than the opposite: the tendency to replace all existing content by a new one created from scratch, in cases where it is no needed at all. In any case, as you said, the problem is not unique to Commons galleries (but the more dissemination they have, the lower the risk of this occurring). MGeog2022 (talk) 10:18, 5 August 2024 (UTC)[reply]
It doesn't really happen when users go directly to the categories and look there. Enhancing999 (talk) 10:20, 5 August 2024 (UTC)[reply]
Yes, galleries that only exist to replicate a category make no sense. But many others, even if they only have a subset of the images in the category, help to present them in a structured way, or to focus in the most important ones (if the category has many hundreds of elements, or many subcategories, nobody would view all of them, or be easily able to find the most important ones; good galleries fulfill this, but the matter is to have good galleries and keep them updated). MGeog2022 (talk) 10:30, 5 August 2024 (UTC)[reply]
I like gallery pages, use them often. I also made some gallery pages, see an overview on my user page. My remarks for this discussion:
  • Indeed, they need to have a clear purpose, direction, and theme. The purpose of gallery pages can be found on Commons:Galleries: "to present readers with a structured and meaningful collection of the media found here on Wikimedia Commons." Themes can be endlessly: navigating within a big category, with links to subcategories like Headgear; an impression of how something looks like, like a populated place or a landscape; an overview of the works of an artist; an overview of the live of a famous person.
  • If the images in a gallery page are old or otherwise not good enough, you can always replace them with more recent or better ones. This is a wiki, so everybody may contribute, also to existing gallery pages. Can we mark a gallery page with something like: This gallery page needs some TLC (and give the reason why it should have TLC)?
  • Navigation: see Category:Gallery pages. The problem is, that gallery pages often lack at least one of its subcategories. Cause may be: in the past the rule was to add either a topic OR a gallery category. Even the current text in Commons:Galleries only says that you should add the category with the same name (so a topic category) and does not say anything about Category:Gallery pages. I would like to make it a rule that a gallery page always has to be put into at least two categories: one topic and one gallery category.
  • Agree: galleries that only exist to replicate a category make no sense, or only contain a few files. I see too many gallery pages that are disappointing, and where the focus of the creator certainly was not to show a meaningful collection of media. Can we make it a rule, one way or another, that a gallery page should either be about a very large category (200+ files) or about at least a couple of categories (subcategories included)? Because I see too many categories with only a few (1-3) files, but I have no good tool to address that.
  • Perhaps a reward system for good quality gallery pages, just like for photos? Perhaps revive Commons:Featured galleries? That would also make it easier to choose from if links to galleries are placed on the main page of Commons.
JopkeB (talk) 18:22, 6 August 2024 (UTC)[reply]
I don't think that "a gallery page should either be about a very large category (200+ files) or about at least a couple of categories" is a particularly good rule. One of the examples I gave above (Pioneer Square Park) would be useful even if those were the only images in that category. Similarly, I think, for Seattle and the Orient: even if that book were a little smaller, it's a good way to handle a book. - Jmabel ! talk 21:39, 6 August 2024 (UTC)[reply]
We can discuss the numbers, my proposal is just a starting point. I want to get rid of all those disappointing gallery pages, that do not have any added value, and to have a tool to address that. Category:Pioneer Square Park (Seattle) has also seven subcategories, that is enough for me. JopkeB (talk) 07:13, 7 August 2024 (UTC)[reply]
I think that any rule should be applied to the gallery itself, not to the category or categories to which the included files belong. If a gallery presents a number of files in a structured way, including good descriptions, etc., there is no reason to remove it. If a gallery shows all or almost all of the files of a category that includes not many files, and doesn't show any information that isn't in the file names of the shown files, or doesn't present them in any particular structured way, or if the gallery includes, let's say, only 1 or 2 files and there isn't a special reason to have it, the gallery could well be deleted. MGeog2022 (talk) 13:02, 7 August 2024 (UTC)[reply]
For example, just showing the names/descriptions of all the files in a category in more than 1 language (file name can only be in one language), can be a good reason to have a gallery in some cases. The existence of barely viewed galleries, by itself, causes no harm to anyone. MGeog2022 (talk) 13:09, 7 August 2024 (UTC)[reply]
That is a good point, I did not think of that. But then there should be a note in the gallery page with this reason, to prevent misunderstanding. JopkeB (talk) 14:29, 7 August 2024 (UTC)[reply]
Reviving Commons:Featured galleries would be a good thing, as it would encourage improving galleries in general. But, aside from that, I think that special galleries, or rather, systems of galleries, such as the Atlas of the World (perhaps even there are no more than this, but others such as city galleries could be organized in a similar way), that are like a project in themselves, deserve a direct link from Commons main page. MGeog2022 (talk) 11:49, 7 August 2024 (UTC)[reply]

Santo Domingo de Guzmán

[edit]

Category:Santo Domingo de Guzmán, Dominican Republic might need renaming. wikipedias say "Santo Domingo, originalmente como Santo Domingo de Guzmán..." RZuo (talk) 15:17, 4 August 2024 (UTC)[reply]

How is this a VP-level issue, rather than just a reason for a CfD? - Jmabel ! talk 19:48, 4 August 2024 (UTC)[reply]
Somehow the cfd tool doesn't seem to work. Enhancing999 (talk) 15:19, 7 August 2024 (UTC)[reply]
Tool worked fine for me. - Jmabel ! talk 19:18, 7 August 2024 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jmabel ! talk 19:18, 7 August 2024 (UTC)

August 05

[edit]

Talk pages of deletion requests – again

[edit]

Can we now have a final consensus on the problematic issue of using the said talk pages as discussion areas of deletion requests instead of deletion requests pages themselves? Another case, by @Estrellato: (this one), which I have now moved to the main discussion page where it should be.

Other cases I recently passed by:

Context: Commons:Village pump/Proposals/Archive/2023/11#Disabling talk pages of deletion requests (no consensus or conclusion). JWilz12345 (Talk|Contrib's.) 08:16, 5 August 2024 (UTC)[reply]

 Support this change. There are, so far, over seven thousand deletion requests with talk pages (alphabetical list); at a glance, most of them were created by inexperienced or logged-out users in an attempt to respond to a deletion request, and many of them were never acknowledged by other editors. Blocking the creation of these pages, at least by non-autoconfirmed users, will do a lot to help these users get back on the right track. Omphalographer (talk) 05:17, 6 August 2024 (UTC)[reply]
@Omphalographer how about non-autopatrolled users instead, so to be more prudent in the proper use of the said talk pages? The Sarajevo railway station DR talk page was actually created by an autoconfirmed user (My-wiki-photos). JWilz12345 (Talk|Contrib's.) 05:47, 6 August 2024 (UTC)[reply]
Ideally, yes! Any level of restriction we can add to creating these pages is a step in the right direction; my point was that even a very slight restriction (like requiring autoconfirmed) would help. Omphalographer (talk) 00:15, 7 August 2024 (UTC)[reply]
I'd probably back any proposal to tighten this. Auto-confirmed at the very least. - Jmabel ! talk 22:42, 6 August 2024 (UTC)[reply]
 Support --Adamant1 (talk) 23:43, 6 August 2024 (UTC)[reply]
✓ Done see Special:AbuseFilter/307 —Matrix(!) {user - talk? - uselesscontributions} 06:15, 7 August 2024 (UTC)[reply]
Thanks @Matrix for the upgraded filter. Thanks also to all Wikimedia Commons users who participated in the old and current discussions. If there are no opposing users, this thread may now be requested for immediate archival. JWilz12345 (Talk|Contrib's.) 08:39, 7 August 2024 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. --—Matrix(!) {user - talk? - uselesscontributions} 08:45, 7 August 2024 (UTC)

August 06

[edit]

Nearcoord and SDC

[edit]

mw:Help:CirrusSearch#Geo_Search

it seems nearcoord doesnt work if a file only has coords in com:sdc.

either nearcoord or sdc has to be tweaked so that they work, or a bot needs to duplicate the sdc to {{Location}} on file pages. RZuo (talk) 14:33, 6 August 2024 (UTC)[reply]

@RZuo: If you have an example search and an example file that should be in the results but is not, please make a task for that in Phabricator.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:38, 6 August 2024 (UTC)[reply]
@RZuo: I would expect that including an empty {{Location}} template in the file's description would be enough. The template will automatically use the co-ordinates from structured data if it doesn't have any parameters, so there's no need to copy the co-ordinates. Have you tries that? --bjh21 (talk) 15:04, 6 August 2024 (UTC)[reply]
good tip! it works. i forgot about that.
so a bot needs to add that template to those files. RZuo (talk) 15:16, 6 August 2024 (UTC)[reply]
@RZuo: you can request at Commons:Bots/Work requests. - Jmabel ! talk 19:19, 7 August 2024 (UTC)[reply]

File:Leo K Thorsness.jpg

[edit]

Can someone improve the crop on File:Leo K Thorsness.jpg? When using dark mode it looks like this: https://i.imgur.com/kS6tgE5.png Thanks, Polygnotus (talk) 14:44, 6 August 2024 (UTC)[reply]

@Polygnotus: ✓ Done, but it took me a couple of tries with CropTool, which doesn't respect dark mode.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 16:41, 6 August 2024 (UTC)[reply]
@User:Jeff G. Thank you that looks a lot better! Polygnotus (talk) 17:26, 6 August 2024 (UTC)[reply]
@Polygnotus: You're welcome!   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 00:36, 7 August 2024 (UTC)[reply]

Reminder! Vote closing soon to fill vacancies of the first U4C

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

Dear all,

The voting period for the Universal Code of Conduct Coordinating Committee (U4C) is closing soon. It is open through 10 August 2024. Read the information on the voting page on Meta-wiki to learn more about voting and voter eligibility. If you are eligible to vote and have not voted in this special election, it is important that you vote now.

Why should you vote? The U4C is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community input into the committee membership is critical to the success of the UCoC.

Please share this message with members of your community so they can participate as well.

In cooperation with the U4C,

-- Keegan (WMF) (talk) 15:29, 6 August 2024 (UTC)[reply]

Image file seems broken

[edit]

File:Northern England.svg is an image of a map but it looks like it's broken. The image fails to appear on the Wikipedia articles it's on for at least a week. Someone please check and correct the issue here. Plarety2 (talk) 22:45, 6 August 2024 (UTC)[reply]

Looks like a namespace problem:
error on line 5 at column 33: xmlns:i: '&ns_ai;' is not a valid URI
That looks like Adobe Illustrator using entities and then another application rewriting the file without expanding the entities.
Glrx (talk) 01:18, 7 August 2024 (UTC)[reply]
@Plarety2: should be fixed now. Glrx (talk) 04:06, 7 August 2024 (UTC)[reply]

August 07

[edit]

Nominating for both speedy and community revue deletion has a problem

[edit]

It appears that the nominator used speedy within the regular deletion process and when you hit the button to remove the speedy, it corrupts the initial nomination. See: https://commons.wikimedia.org/w/index.php?title=File:Dunga_Rodrigues,_escritora_e_pianista._Cuiab%C3%A1.jpg&diff=prev&oldid=907116342 Can anything be done to fix this, other than the nominator not using both speedy and the regular deletion process at the same time? --RAN (talk) 01:20, 7 August 2024 (UTC)[reply]

New type of tram in Częstochowa

[edit]

Examples in Category:Trams in Częstochowa by type. It is clearly not a Pesa Twist 2010N. In de description one talks of Twist II. Smiley.toerist (talk) 11:58, 7 August 2024 (UTC)[reply]

Category:Files that need updating

[edit]

Any idea what should be in there? It looks like almost everything "needs updating". Shouldn't that be the exception? Enhancing999 (talk) 15:18, 7 August 2024 (UTC)[reply]

You put files in there that track statistical trends and are meant to be used in general Wikipedia articles (vs. articles covering a specific moment in time). A cursory glance tells me lots of files in that category don't belong there, though, like maps tracking hurricane paths that took place years ago. ReneeWrites (talk) 17:28, 7 August 2024 (UTC)[reply]
I think a substantial part of the problem is the {{Hurricane season auto track map}} template, which automatically adds {{current}} to the file page by default. Omphalographer (talk) 17:45, 7 August 2024 (UTC)[reply]

August 08

[edit]

Good news: Cat-a-lot works again like a charm!

[edit]

For who likes to work with Cat-a-lot: since the beginning of this year there were problems. But now it works well again, also for moving/copying subcategories that have subcategories themselves. (See MediaWiki_talk:Gadget-Cat-a-lot.js#Problems_categorizing_category_pages for more information.) I now can start to clean up my list with postpones jobs because of this problem. JopkeB (talk) 03:37, 8 August 2024 (UTC)[reply]

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