Commons:Village pump

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

Shortcut: COM:VP

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
🌐 Village pumps for other languages
COMMONS DISCUSSION PAGES
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 Should we convert all TIFFs to JPEGs? 39 25 Zache 2024-08-22 07:14
2 Semi-protection on the Village Pump? 14 9 Yann 2024-08-17 07:55
3 Further dissemination of Wikimedia Commons Atlas of the World needed 42 8 Broichmore 2024-08-22 12:32
4 Add "Upload file" link for mobile? 22 10 Enhancing999 2024-08-15 12:57
5 Flickr2Commons 27 9 Ooligan 2024-08-21 23:04
6 Different Types of Flagmaps 9 5 Adamant1 2024-08-21 09:26
7 Uploads stopped working 9 6 Enhancing999 2024-08-19 09:59
8 Category:Jeu de l'assiette and Category:Belltafel 3 2 Jonas kork 2024-08-15 07:39
9 Lists of GFDL 11 5 Enhancing999 2024-08-19 09:38
10 People by location 14 8 Adamant1 2024-08-21 10:41
11 How to delete metadata of a picture? 12 6 TheDJ 2024-08-20 11:32
12 POTY new rules 2 2 Enhancing999 2024-08-22 06:52
13 Uploaded public transport photos - how to let people know they can use them in articles 10 7 Enhancing999 2024-08-19 09:29
14 Mention of overwriting cases at COM:FLICKR 2 2 Enhancing999 2024-08-19 09:41
15 Discussion about Template:Keep local on enwiki 1 1 Matrix 2024-08-17 06:36
16 Intentional footprints 4 4 Tuvalkin 2024-08-19 17:34
17 Which Stena line ship? 8 4 Smiley.toerist 2024-08-20 16:52
18 Showing wrong text for {{Diffusion by condition}} and {{CatDiffuse}} 3 2 JopkeB 2024-08-19 15:34
19 Improvements to "Use this file" facility 2 2 Prototyperspective 2024-08-20 12:25
20 Cactus expert needed 2 2 Asclepias 2024-08-19 12:17
21 Category:Military units and formations of the British Army 1 1 Jmabel 2024-08-20 03:50
22 Keep which 6 4 Jmabel 2024-08-21 23:00
23 No error message for same file names in Upload Wizard 1 1 Saiphani02 2024-08-20 09:00
24 Help needed cleaning up Category:Media from Telegram 3 2 Cryptic-waveform 2024-08-21 11:15
25 Photo challenge June results 1 1 Jarekt 2024-08-21 03:33
26 Pulling cords 9 4 Jeff G. 2024-08-22 12:06
27 Who painted this? 1 1 LA2 2024-08-21 13:31
28 Looking for page about having an account 3 3 Enhancing999 2024-08-22 06:48
29 Username renaming 6 5 Prototyperspective 2024-08-21 20:13
30 Is this a breach of copyright? 2 2 Jmabel 2024-08-21 17:50
31 Boots 2 2 ReneeWrites 2024-08-21 22:49
32 Uploading larger files 2 2 Geohakkeri 2024-08-21 22:39
33 Depicts 3 3 GPSLeo 2024-08-22 05:55
34 Categories related to war resistors 1 1 Jmabel 2024-08-22 00:37
35 Is renaming categories with an English name to local language names a good idea? 9 6 Prototyperspective 2024-08-22 09:19
36 Origin of locations in infoboxes 5 5 Zache 2024-08-22 11:15
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.
Water pump next to the church in the town center of Doel. Doel, Beveren, East Flanders, Belgium. [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.

August 03

Should we convert all TIFFs to JPEGs?

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]
  •  Oppose, including per Gestumblindi. -- Ooligan (talk) 19:10, 8 August 2024 (UTC)[reply]

 Comment One thing that is unclear to me is why the current thumbnail links are not enough? Is there some technical aspect that needs to be fixed, or are the current links too hard to find or understand what they do? From a technical perspective, it should be a server-side task to generate jpeg versions or download links to jpegs automatically instead of duplicating photos manually. Mediawiki already does that, so I am asking what you think is currently failing and what should be done to fix it. --Zache (talk) 16:53, 12 August 2024 (UTC)[reply]

Agree. If mass-conversion is thought to generate better quality jpeg, it's a sign that there is a problem with the current sever configuration. (That one should have uploaded jpegs to start with is another issue.) Enhancing999 (talk) 11:20, 17 August 2024 (UTC)[reply]
And also if the problem is that people wont find a way to download image as good quality jpeg, we could just add a button "Download as full-resolution JPEG" which would link to jpeg version. --Zache (talk) 07:14, 22 August 2024 (UTC)[reply]
 Comment There are different cases:
  • single-page TIFF files already using JPG compression internally:  Support lossless conversion to JPG outer container, unless there are special reasons against
  • single-page 8-bpp uncompressed TIFF files:  Support lossless conversion to 8-bpp PNG, unless there are special reasons against
  • single-page 16-bpp uncompressed TIFF files:  Support lossless conversion to 16-bpp PNG, unless there are special reasons against
  • multi-page TIFF files:  Oppose any conversion since no viable alternative exists
So I  Oppose lossy conversion of whatever types of TIFF into JPG.
TIFF is NOT the great lossless format. The cool lossless format is PNG (except for animations and multi-page images). Taylor 49 (talk) 14:56, 18 August 2024 (UTC)[reply]
What we desperately need is straightforward guidance on what formats to use for uploaded files, I’m yet to see it.
If I have, for example, the opportunity to upload a historical, and or “art” image in jpg, webp , or png, which should I use? _Broichmore (talk) 17:25, 21 August 2024 (UTC)[reply]
Where does the image come from?
  • preferably keep it in the format it already is (no conversion is better than conversion, unless you are sure that the opposite applies in the given case)
  • if the image is a diagram, use always PNG
  • if the image is small (say up to 2 Mpixel), use PNG
Taylor 49 (talk) 21:40, 21 August 2024 (UTC)[reply]

Semi-protection on the Village Pump?

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]
That sounds reasonable :) MedivalNerd (talk) 20:45, 14 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]
Can we have it back? Non admins are now revert warring with Ips Enhancing999 (talk) 07:47, 17 August 2024 (UTC)[reply]
✓ Done I semi-protected it again, as per [1]. Yann (talk) 07:55, 17 August 2024 (UTC)[reply]

August 04

Further dissemination of Wikimedia Commons Atlas of the World needed

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]
The existence of barely viewed galleries, by itself, causes no harm to anyone. @MGeog2022: As far as I know there are no metrics for how many views certain galleries get. Assuming there's some that have either no or extremely low views it's still a time suck maintaining them and just makes it that much harder for people to finding good galleries. Look at it like a museum with near infinite space that we are custodians of. To many niche, half thought out exhibits just detracts from educating our costumers and puts us in a position where we are wasting more time on dusting off or organizing things our costumers don't care about to begin with. Instead of building exhibits that people are actually interesting in and get educational value out of.
At least for me 99% of my time on here is acting as a glorified janitor. I much rather be uploading images and creating eductional exhibits for people. But there's just to much cleaning and reorganizing that needs to be done in most areas to even get to that point. Be it galleries, categories, or whatever, but the issue is particularly bad with galleries. --Adamant1 (talk) 04:14, 8 August 2024 (UTC)[reply]
@Adamant1, in any gallery page, you can be how many views per day it has at "History -> Pageviews Analysis".
I'm not saying that having galleries with few/almost none views is good, what I wanted to say is that content in Commons or any other Wikimedia project is not valued according to how many views it has. If for whatever reason people do not usually look at a well-done wiki page, it isn't a reason at all to propose its deletion. MGeog2022 (talk) 10:03, 8 August 2024 (UTC)[reply]
@MGeog2022: Thanks for the info. I wasn't aware that was an option. You make a good point, but I do think we are ultimately here to create things other people will see and get value out of. Not to say we should delete everything that has a low view count either. I think there's a line with galleries in particular where deletion is justified if it both has extremely low views and is badly designed without a chance of salvaging it though. But I have no issue with an extremely well designed gallery that also happens to have low viewer numbers for whatever reason either. Something like reviving Commons:Featured galleries would certainly help with that. --Adamant1 (talk) 10:45, 8 August 2024 (UTC)[reply]
Yes, and is badly designed is the point I was referring to. If it has low views, it may not be worth improving the gallery in those cases. MGeog2022 (talk) 10:51, 8 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]
It's kind of a side thing but we should really create a guideline beyond Commons:Galleries (which at least IMO is to focused on the technical) that lays out what makes a "good" gallery and provides some standard for them. I'm not sure it's possible to, or worth, encouraging people to improve galleries in general without clear standards for what makes one good to begin with though. --Adamant1 (talk) 15:23, 8 August 2024 (UTC)[reply]
Atlas of the World deserves a direct link from Commons main page: what do you think about that? If this view is shared by others, how is Commons main page updated (for example, I can't edit it, even having more than 1,000 edits in Commons, and obviously there is a good reason for it)? MGeog2022 (talk) 11:16, 10 August 2024 (UTC)[reply]
As a lover of maps in Commons, I stumbled regularly across these gallery pages, but the lack of curation let me ignore them completely, and I don't think I will change my attitude. It takes so much effort to categories maps properly (and the category system is may more dynamic than galleries), and we have so many ten thousand maps that are uncategorized (so not even linked to their subject), that picking a the nicest maps to showcase the subject in a dedicated Atlas-gallery-page seems like wasted effort to me. Sorry. --Enyavar (talk) 12:31, 10 August 2024 (UTC)[reply]
@Enyavar, thanks for your work categorizing maps, I wasn't aware of this category. I'm struck by the fact that people upload maps without any information at all (it's more likely to happen with photos, but with maps or other publications it's really striking).
If the Atlas was more known, it would be in a better state for sure. But in any case, I agree that many maps aren't and won't never be in a gallery, so perhaps Category:Maps itself could be linked from Commons main page, as the best "atlas" that we can offer to users. MGeog2022 (talk) 14:53, 10 August 2024 (UTC)[reply]
To be more precise, both maps category and Atlas of the World are already linked from main page, but they are hidden by default inside "By type -> Images". I think this should be restructured to make them more visible. They are at the same level as photos, diagrams or drawings, but an Atlas (and we could consider Maps category also as such) isn't the same as millions of photos without a defined subject, it's something whose presence should be more visible. I think they (Atlas of the World and maps category) should be directly in "Content - by topic", probably as a new entire topic to be added to Nature, Science etc. How could this change be achieved? MGeog2022 (talk) 15:02, 10 August 2024 (UTC)[reply]
I created this proposal for the change, to be voted. On the other side, I added a link to the Atlas of the World at Atlas English Wikipedia article, in the section External links -> Online atlases, in an effort to make it a bit better known MGeog2022 (talk) 12:07, 13 August 2024 (UTC)[reply]
I  Support utilizing gallery pages more often. I also love galleries and contributed on gallery pages, including atlas pages. Sbb1413 (he) (talk • contribs • uploads) 12:46, 14 August 2024 (UTC)[reply]
If anyone knows of a way, of ignoring galleries and excluding them from search results, I would be very interested.
At the moment when "search is employed" they have precedence over Cat folders.
I detest galleries, and see them as irrelevant to the project. This is a databank, not a presentational social media platform. I want to look at all the images for a subject, and choose items for using on remote websites. Galleries get in the way of that. I don’t want being spoon fed images, I want to make my own choice. If I never see another one. I’ll be happy. Broichmore (talk) 11:18, 21 August 2024 (UTC)[reply]
I've used them pretty effectively as a way to track what I've uploaded and/or organized related to a specific topic. Kind of like an on going catalog of images related to a particular project I'm working on at the time. For instance Category:Postcards published by Frank Patterson. They seem totally pointless in a lot of other cases though. Like there's a ton of galleries for flags where they are essentially empty except for a couple of images and a bunch of "no image" thumbnails because the flags either haven't been uploaded to Commons yet or aren't PD to begin with. Really, in those cases galleries are just being used as superficial Wikipedia articles, which I'd agree isn't the point in the project. What we need is some clear standards about when it's appropriate to create a category or not and a few people to put the time into cutting out the cruft. --Adamant1 (talk) 12:59, 21 August 2024 (UTC)[reply]
@Adamant1: There is already a section dedicated to galleries vs. categories at COM:GAL. It says, Categories should contain all files related to the subject while galleries should contain a sample of files related to the subject. Ideally, galleries should contain the best of what we have. All files should be in at least one category, but not all files should be in a gallery. Sbb1413 (he) (talk • contribs • uploads) 13:43, 21 August 2024 (UTC)[reply]
I'm aware. I didn't think anyone is aware of or applying it properly though. The word "ideally" probably doesn't help either. --Adamant1 (talk) 14:31, 21 August 2024 (UTC)[reply]
There's a strong case for making a gallery for flags, where one of each is represented for identification purposes. However, if we have a category, filled with only 50 items (or even less than 100), I see no reason for them.
Making categories for any other reason than identification of the particular subject is pointless on this particular platform.
I can well see the need, for representational pictures of the 3 (or 6) types of camel, but beyond that no! _Broichmore (talk) 17:17, 21 August 2024 (UTC)[reply]
I'm going to point again at something where I built a gallery that could not possibly be usefully substituted by a category: Romanian Orthodox churches in Bucharest. There are an enormous number of such churches, many of them very similar in appearance but with subtle differences. If you have a photo of something that you know is a Romanian Orthodox church in Bucharest, without a gallery page like this it would be very time-consuming to determine exactly what church it is; with this gallery, it is rather straightforward. I frankly think we need hundreds, maybe thousands, of analogous pages on different topics, if only for our own internal use for people who add categories to inadequately described third-party images (or their own images where they failed to take decent notes). - Jmabel ! talk 17:40, 21 August 2024 (UTC)[reply]
@Broichmore: Sure, I think you could make a strong case for having galleries about flags. My comment was less about the merits of galleries for flags then pointing out multiple people made galleries for flags where most of the images didn't exist to begin with and were simply a "no image" thumbnail with a title, which I think you'd agree isn't really the point in galleries. The question (or at least it's the question to me) is what part of the guidelines or consensus led to multiple people creating galleries for flags that contained no or very little images to begin with. Who knows, but that's why I say we need clearer guidelines and people to clean up the cruft. Clearly it's not helpful to have a large amount of galleries that only have a few or no images and can't be expanded because most of source material isn't on here to begin with and probably never will be due to being copyrighted or whatever. --Adamant1 (talk) 07:04, 22 August 2024 (UTC)[reply]
Reading back, I've not been too clear. Apologies.
Galleries, should exist for identification of a particular subject’s components. A gallery should show a single representational picture of item. Certain items may demand two or more. Aeroplanes, a side and top view. A building may have to be represented by as many as 4, if the sides are radically different from each other. Jmabel's Places of worship in Seattle, Romanian Orthodox churches in Bucharest is a good exemplar of what’s required.
Where and on what basis should we not? I'm thinking, if Wikipedia has one already, then we don’t need to duplicate it. In any event, I'm inclined to think Wikipedia is a better place for this kind of thing, and ot does have a bigger audience, which makes the effort of making one, more worthwhile. Not forgetting these pages require maintenance, and there are more willing hands there.
What I'd like to see is more links on Wikipedia to commons, after all we are liberal in providing links to Wikipedia here, whereas the reverse could be vastly improved on. Broichmore (talk) 12:32, 22 August 2024 (UTC)[reply]
@Broichmore: In 255+ languages?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:34, 22 August 2024 (UTC)[reply]

August 08

Tracked in Phabricator
Task T372078

Hello friends. Today at a conference I was helping an iOS user debug a poor quality app he was using to upload files to Commons. The app was bad enough that we started looking for alternative ways to upload files, and I had him try uploading files through his iOS Safari browser instead. He opened Commons in his browser and there was no upload link, which surprised me. So I created phab:T372078 and wrote a patch to add "Upload file" to the left menu of the Minerva (mobile) skin. Clicking on it takes you to Special:UploadWizard.

When I went to go get this patch merged, someone told me that this "Upload file" link might not be wanted because it would increase uploads of unwanted images. The implication was that mobile editors have a tendency to upload images that are inappropriate for Commons. So I'd like to check with the community and see how y'all feel about adding an "Upload file" link for mobile editors. Thoughts? If this is a bad idea I will abandon my patch. Thanks. –Novem Linguae (talk) 20:28, 8 August 2024 (UTC)[reply]

We live in an age where almost everyone surfs the internet on a mobile device most of the time, almost every website is very specifically designed around mobile devices, and most of the time online services request people to download their apps in Google Play or similar marketplaces. Yet, for whatever reason Wikimedia websites aren't just mobile unfriendly, they are mobile hostile. What's worse is that this laptop-centric and desktop-centric thinking actively excludes the vast majority of people from developing countries, I've met plenty of rural Filipino men and women in their 20's this year that have never even seen a laptop. How can we expect these people to contribute free educational media if their browser specifically tells them that this website is only for consuming and not producing? It's time to get rid of these antiquated restrictions on mobile users. I think that we might have to lobby the Wikimedia Foundation (WMF) to force their developers to edit and contribute at least two (2) whole weeks a year exclusively on mobile devices or hire engineers that only use mobile devices to contribute so they can get some valuable feedback, because they have been ignoring mobile users for years. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:51, 8 August 2024 (UTC)[reply]
  •  Oppose It seems like a lot of COPYVIO comes from screenshots on mobile. Do we really want to make it worse by allowing people to upload directly from their phones? Probably not. It looks like we're already going to block cross project uploads for the same reason and I don't see why we should allow mobile users to upload junk in mass while not allowing people from Wikipedia to do the same. --Adamant1 (talk) 00:39, 9 August 2024 (UTC)[reply]
    @Adamant1 Please provide a link where there is a proposal that is "... going to block cross process project uploads ..." Thank you, -- Ooligan (talk) 07:14, 9 August 2024 (UTC)[reply]
    @Ooligan: Check out Commons:Village_pump/Proposals#Deactivate_cross-wiki_uploads_for_new_users. Technically it's to block uploads from people who don't have special rights but I don't think that negates my point. As it's still a restriction on making it easier for random people from uploading images to Commons in an area that leads to a massive amount of COPYVIO. Although we could restrict this to certain users or something but I'd still be against it because at the end of the day "confirmed" is a pretty low bar and it would kind of defeat the purpose anyway. --Adamant1 (talk) 07:33, 9 August 2024 (UTC)[reply]
    I feel like a big part of the problem with cross-wiki uploads was that the tool encouraged users to do the wrong thing, and thus they did indeed do the wrong thing. That is, the real issue was not that it was "mobile" it was that that was a bad tool with bad UX. I suspect having an upload link on mobile linking to Special:UploadWizard would not have the same type of problems as the cross-wiki upload tool did. Or at least not to the same degree. Bawolff (talk) 08:58, 9 August 2024 (UTC)[reply]
    I do wonder how easy UploadWizard would be to work with on mobile. It's not the most intuitive UI even on desktop. --Adamant1 (talk) 09:59, 9 August 2024 (UTC)[reply]
Sure, please add it. I don't think this has anything to do with cross-wiki uploads. Mobile view of Commons is known to be broken. Enhancing999 (talk) 09:33, 9 August 2024 (UTC)[reply]
Cross-wiki uploads is just another example of where people not uploading images directly through the website on desktop can lead to problems. I'm not claiming they are 100% exactly the same though, but there is some is (or would be) similar issues with both IMO. At the end of the day anything other then directly uploading images through Special:UploadWizard on desktop will just lead to more errors and COPYVIO. --Adamant1 (talk) 09:59, 9 August 2024 (UTC)[reply]
This is much needed. The vast majority of original photos today are from phone cameras. We should make it easy to upload. The question about copyright is not really relevant, it is not linked to the skin used. Geraki TLG 12:28, 9 August 2024 (UTC)[reply]
@Geraki: "The vast majority of original photos today are from phone cameras." Are you saying this about photos in the world at large (in which case I agree) or about Commons uploads (in which case my own impression is that you are wrong, and I'd like to see some sort of evidence for that statement). - Jmabel ! talk 15:12, 9 August 2024 (UTC)[reply]
Without neglecting the need to control COPYVIO and not overburden administrators, not allowing uploads from mobile is a discrimination against people with lower income (and it could even be viewed as racial discrimination, since, for example, black South Africans are much less likely to own a computer than white South Africans), and also against older people in most countries (who are much less likely to use a computer, but they usually use a smartphone), so it should be addressed, provided that it is possible to monitor the profile of each new user and easily detect if he/she is going to make inappropriate use. MGeog2022 (talk) 11:10, 10 August 2024 (UTC)[reply]
Alright, I only see one objection so far, and several supports. Should this stay open for a bit longer or can the patch move forward? –Novem Linguae (talk) 12:29, 11 August 2024 (UTC)[reply]
I think we should try this first limited to autopatrolled users, if there are no problems also for autoconfirmed users and if this also works we can open it for all users. If there are problems we step back to the previous limitation. GPSLeo (talk) 12:42, 11 August 2024 (UTC)[reply]
Any patch I make to the Minerva skin needs to be wiki-agnostic. If we are going to add some logic that only applies to Commons, such as checking for permissions before displaying the link, then we might need to look into MediaWiki:minerva.js or a default gadget or something instead of a Minerva patch. –Novem Linguae (talk) 13:26, 11 August 2024 (UTC)[reply]
As long as we no inter wiki user rights checking we can only do this by blocking after clicking on upload what of course is not a really good solution. GPSLeo (talk) 13:41, 11 August 2024 (UTC)[reply]
I didn't realize that anything on VP would constitute a proposal with voting. I expected that this was some people discussing something they would then propose at COM:Village pump/Proposals. I am objecting to this being a mandate to go ahead. There was no one specific proposal here I felt I could vote on. - Jmabel ! talk 16:56, 11 August 2024 (UTC)[reply]
I have to agree with Jmabel here. This should be an actual proposal with voting and last for the normal time frame of one. This being open for three days regardless of where isn't nearly enough to call it approved regardless though. But this is still the wrong venue and format for it either way. --Adamant1 (talk) 10:39, 12 August 2024 (UTC)[reply]
If someone pursues this in the future, what is the correct page, duration, and process, if I may ask? –Novem Linguae (talk) 11:12, 12 August 2024 (UTC)[reply]
Am I missing something or isn't this just a bug? Enhancing999 (talk) 11:16, 12 August 2024 (UTC)[reply]
Anyone? Does Commons have an RFC process somewhere I can read up on? What board should a future RFC about this be posted on? –Novem Linguae (talk) 12:42, 15 August 2024 (UTC)[reply]
Here we go: Commons:Village_pump/Proposals#Proposal:_fix_bug/feature_of_missing_upload_link_in_some_skins/for_some_devices, you can "vote" to fix the bug. Enhancing999 (talk) 12:57, 15 August 2024 (UTC)[reply]

August 09

Flickr2Commons

Flickr2Commons appears to be down. Does anyone know what is going on? - Jmabel ! talk 00:32, 9 August 2024 (UTC)[reply]

Hello, @Jmabel. I also noted this continuing issue at the "Technical" page here: Commons:Village pump/Technical#Flickr2Commons tool not working for about 24 hours. I get this message currently-
* "Wikimedia Toolforge Error"
* "Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again later."
* "tools-proxy-8.tools.eqiad1.wikimedia.cloud"'
It has been about 40 hours. Other Users are apparently using this same tool without any problems. (located on other continents)
Thanks, -- Ooligan (talk) 06:49, 9 August 2024 (UTC)[reply]
@Jmabel: Not even connecting for me, via Optimum Online in New Jersey, USA, North America. Obviously, I can read and post here.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:16, 9 August 2024 (UTC)[reply]
Via T-Mobile too - "ERR_CONNECTION_ABORTED".   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 11:18, 9 August 2024 (UTC)[reply]
Then "ERR_NETWORK_IO_SUSPENDED" when I put my laptop into hibernation for transport, and again not connecting via Optimum Online.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:28, 9 August 2024 (UTC)[reply]
Toolforge itself is responding just fine, at best 34ms away over 100 pings.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:48, 9 August 2024 (UTC)[reply]
I created issue 320 for Magnus Manske.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:00, 9 August 2024 (UTC)[reply]
Thank you @Jeff G. -- Ooligan (talk) 21:39, 9 August 2024 (UTC)[reply]
Not loading for me in Australia. Bidgee (talk) 22:21, 9 August 2024 (UTC)[reply]
@Ooligan: You're welcome. Then, I got "Wikimedia Toolforge Error" and "Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again later." from tools-proxy-8.tools.eqiad1.wikimedia.cloud and a page titled "504 Gateway Time-out" with "Webservice request timed out". I updated that issue.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:57, 10 August 2024 (UTC)[reply]
Pinging @GFontenelle (WMF) per Commons:Village pump/Archive/2023/06#Flickr Foundation adopts Flickr2Commons.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:07, 10 August 2024 (UTC)[reply]
... and we're back to that "Webservice request timed out" error.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:37, 13 August 2024 (UTC)[reply]
Still.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:06, 16 August 2024 (UTC)[reply]
Tagging @Magnus Manske FYI -- DaxServer (talk) 15:49, 14 August 2024 (UTC)[reply]
Tracked in Phabricator
Task T372451
https://phabricator.wikimedia.org/T372451 M2k~dewiki (talk) 15:56, 14 August 2024 (UTC)[reply]
@M2k~dewiki: "The maintainer doesn't read" Commons talk:Flickr2Commons and "Magnus Manske prefers it if you take tool issues to his Bitbucket." per {{Magnus is not here}} atop that page.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 09:36, 15 August 2024 (UTC)[reply]
@DaxServer: I already pinged him on the 9th per above, to no avail.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 09:38, 15 August 2024 (UTC)[reply]
I wanted to host a copy, but I am constantly get barricaded at finding all the dependencies required. I hope to get it working in case the tool isn't back up soon -- DaxServer (talk) 20:08, 15 August 2024 (UTC)[reply]
I was able to get it up here https://flickr2commons-ng.toolforge.org/ However, it now suffers from now being to read the credentials for Commons DB replica. The code is adjusted accordingly to the tutorial on Wikitech. If someone has an idea why it's not working, please leave me a message 🙏. I'll chat with someone on IRC tomorrow to debug. -- DaxServer (talk) 22:04, 15 August 2024 (UTC)[reply]
Now, it appears to be interminably "Loading..."   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:09, 21 August 2024 (UTC)[reply]

This is all particularly annoying because Flickypedia is also down. - Jmabel ! talk 22:16, 15 August 2024 (UTC)[reply]

Yeah, that's terrible. --A1Cafel (talk) 04:03, 16 August 2024 (UTC)[reply]
What's the deal with Magnus Manske? Is he just not working on it anymore or something? --Adamant1 (talk) 10:11, 16 August 2024 (UTC)[reply]

August 11

Different Types of Flagmaps

Corsica-Flagmap.svg
Flag-map of Corsica.svg

Most flag maps on Wikimedia Commons follow the naming format 'Flag_map_of_Country.' These maps have been created by various contributors, each using different base maps with varying levels of accuracy. Typically, they feature thicker border strokes in the colors of the respective flags. However, I found the inconsistencies across these maps unsatisfactory, so I created my own set of flag maps using OpenStreetMap as the base. My maps are highly accurate and consistent, with all borders depicted using black, slightly thinner strokes. So far, I have completed maps for European and Asian countries and plan to expand to other continents. My flag maps follow the naming format 'Country-Flagmap.' I'm writing this to prevent renaming conflicts and to foster consensus among users. Thank you. Kamran.nef (talk) 13:24, 11 August 2024 (UTC)[reply]

(As someone who loves both flags and maps, I’d like to see this kind of hybrid monstrosity relegated to the trashbin of bad ideas. -- Tuválkin ✉ ✇ 18:15, 14 August 2024 (UTC))[reply]
Not in topic but, i wanted to thank you for making these types of Flag maps, as a notable Flag maps lover, i used more times your basemaps (mostly Russia and Greenland), though i never understood how you manage to do these with Openstreetmap, they are still usefull, so, thanks again ;) OttavianoUrsu (talk) 07:35, 19 August 2024 (UTC)[reply]
 Comment One file had recently got renamed from File:Brittany-Flagmap.svg to File:Flag map of Brittany.svg in accordance with Category:Flag maps of regions of France and Category:Flag maps of Europe. There are gazillions of such files around. Files by "Kamran.nef", highly accurate and consistent, with all borders depicted using black slightly thinner strokes. How many of such files do we need? Taylor 49 (talk) 15:44, 18 August 2024 (UTC)[reply]
 Comment OK, I agree with the idea that highly consistent flagmaps by User:Kamran.nef can be named xxxx-Flagmap.svg. Taylor 49 (talk) 16:07, 18 August 2024 (UTC)[reply]
Thank you, I hope to add more flagmaps soon. Kamran.nef (talk) 16:34, 19 August 2024 (UTC)[reply]
Agree but do not want to start aggressive deletionism. Taylor 49 (talk) 21:28, 20 August 2024 (UTC)[reply]
Yeah, me neither. I'm not advocating for that. I do think the images are OOS personal artwork though. --Adamant1 (talk) 09:26, 21 August 2024 (UTC)[reply]

August 12

August 13

Uploads stopped working

I've tried repeatedly to upload a pic, it sits doing nothing for ages, then throws up this error message:

Request from 82.41.2.30 via cp3069 cp3069, Varnish XID 90145027 Error: 503, Backend fetch failed at Tue, 13 Aug 2024 21:11:42 GMT

Uploads were working fine earlier this evening, it is just in the last half hour or so. Thanks for any insight! - MPF (talk) 21:16, 13 August 2024 (UTC)[reply]

Working now! - MPF (talk) 22:01, 13 August 2024 (UTC)[reply]
Apparently there was some kind of hamster strike at the WMF servers. I also got messages that because of high database load I couldn't see the edits of the last 720 seconds or so on my watch list. --Rosenzweig τ 22:54, 13 August 2024 (UTC)[reply]
Thanks! Hope the hamsters are being offered better pay now! - MPF (talk) 00:10, 14 August 2024 (UTC)[reply]
@MPF: The hamster beatings will continue until morale improves. :) Seriously, though, I got a similar error message and reported it via phab:T372473.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:15, 14 August 2024 (UTC)[reply]

Upload failed repeatedly for me just now; the image is only ~500Kb. Page deletion on Wikispecies also failing. Both worked eventually, after several attempts. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:06, 14 August 2024 (UTC)[reply]

The hamster strike apparently continues. It just took me over 20 minutes to add some categories to a page. --Rosenzweig τ 14:29, 14 August 2024 (UTC)[reply]
Yeah, I ran into this yesterday and then again today. Whenever it's down for long enough, it means the upload jobs I'm running (which can take up to an hour) give up after several retries and I have to restart the process from scratch. hinnk (talk) 21:08, 14 August 2024 (UTC)[reply]
Any idea why there were these problems last week? Enhancing999 (talk) 09:59, 19 August 2024 (UTC)[reply]

August 14

Category:Jeu de l'assiette and Category:Belltafel

I believe these two categories deal with the same game. fr:Jeu de l'assiette quotes a source from the 17th century, putting it in a similar timeframe to Belltafel = de:Pielkentafel. In England the game was called shovel board (related to but different from shuffleboard). Can the two categories be merged? Should they be kept separate, but both be put into (new) category:shovelboard that collects the cultural/regional variants? --Jonas kork (talk) 08:05, 14 August 2024 (UTC)[reply]

I'd keep both categories, but would categorize them under Category:Table shuffleboard. Cryptic-waveform (talk) 21:24, 14 August 2024 (UTC)[reply]
Sounds good, done! Thanks for the suggestion! --Jonas kork (talk) 07:39, 15 August 2024 (UTC)[reply]

Lists of GFDL

Hello!

I have made some lists at m:User:MGA73/GFDL files/Categories of the number of files licensed GFDL on all the wikis I could locate (updated since this). The lists look like this example for Wikinews:

QID Category Files Remarks
d:Q7237102 n:ar:Category:صور رخصة جنو 0
d:Q61435437 n:ar:Category:لقطة شاشة لصفحة ويكي الأخبار 53
d:Q7136442 n:ar:Category:لقطة شاشة لصفحة ويكيبيديا 3
d:Q7237102 n:en:Category:GFDL files 43
d:Q7237102 n:fa:Category:پرونده‌های رسانه‌ای تحت مجوز گنو 2
d:Q7237102 n:he:Category:קבצים ברישיון GFDL 13
d:Q8109484 n:it:Category:GFDL 1
d:Q7459784 n:it:Category:Immagini GFDL-Utente 0
d:Q7237102 n:pl:Category:GFDL 4
Sub total 119

I would like to find out how many files that can't be moved to Commons because Commons do not accept files licensed GFDL only after 15 October 2018.

There are many wikis and many languages I do not understand. So if you speak "Foo language" you are very welcome to check "Foo wikis". If the files are licensed correctly etc. you can Export them to Commons. If you need help setting up FileImporter just let me know.

If the files are not okay or does not look usable then you can nominate them for deletion locally. --MGA73 (talk) 13:08, 14 August 2024 (UTC)[reply]

MGA73, I looked through n:pl:Category:GFDL and those files would be likely deleted on Commons due to {{No permission}} --Jarekt (talk) 13:53, 16 August 2024 (UTC)[reply]
Thank you Jarekt! Yeah there can be other reasons than just the date. Some photos also have FOP issues. --MGA73 (talk) 17:15, 16 August 2024 (UTC)[reply]
The four files of pl.wikinews would probably not be deleted for that reason, or at least it's not obvious.
  • "Plik:1-7326 g.jpg" was licensed with GFDL at its source. The related pl.wikinews story gives it as an example of a montage on an external website that reused a GFDL-licensed Commons image. The external reuse initially did not comply with the GFDL requirements for reuses, but that was corrected after Wikimedians contacted the website. There are archived copies of the external website where the GFDL is seen.
  • "Plik:SG hack1.png" is a screen capture of a webpage of pl.wikipedia from April Fool's day in 2008, claiming to be created by hackers. it contains 2 photographs
  • "Plik:Konferencja zachlebem03.jpg" says that the permission was given by the photographer. It could probably be kept per "Grandfathered old files".
  • "Plik:Kupony Lotto wykorzystane przez tvn24.png" may be a more complex case. It is an example of a modified version on an external website that did not comply with the reuse requirements of a CC BY-SA 2.5 licensed Commons image. The pl.wikinews article says that the image was removed from the external website. The pl.wikinews file description page says that the external website accepted to publish the modified version under the GFDL, which is strange. There does not seem to be an archived copy of that, so that could be difficult to verify 14 years later. However, the change in the modified version looks rather non creative and it could be uncopyrightable. An argument could be made that it could be used with the CC license of the original Commons image.
-- Asclepias (talk) 22:16, 16 August 2024 (UTC)[reply]
Asclepias,
Those last 2 files likely comply with standards at a time of the upload, but I do not think are suitable for transfer to Commons as they do not comply with current standards. --Jarekt (talk) 02:47, 17 August 2024 (UTC)[reply]
@Asclepias@Jarekt@MGA73 one image at English Wikinews licensed as such may need to stay there. It is their local copy of File:14-02-04-Parlement-européen-Strasbourg-RalfR-046.jpg, one of the infamous buildings of France that does not allow commercial FoP and is one of ADAGP's prized architectural possessions vs. inclusion in Wikipedias. JWilz12345 (Talk|Contrib's.) 05:35, 17 August 2024 (UTC)[reply]
"Plik:1-7326 g.jpg": We cannot require that a file have a Commons LicenseReview template when the file is on another Wikimedia website and not on Commons. The report on pl.wikinews was done by a user who was a pl.wikipedia administrator and that is very much a good license review, and even better because it is more detailed. Also, an archived copy of the source shows the mention that the image is under the GFDL. The web.archive copy apparently did not capture the image itself, but the text leaves no doubt that it is the image in question. The explicit review on pl.wikinews is already sufficient IMHO, and the archived webpage adds more confirmation. -- Asclepias (talk) 14:06, 17 August 2024 (UTC)[reply]
@Asclepias I guess the issue is that the process of "file transfer" is download from one site and new upload to Commons with my name as uploader. Since it is a new upload, I apply today's standards to files uploaded 15 years ago. I do not know if {{Grandfathered old file}} applies to new (re)uploads. Plenty of files I uploaded or transferred over the years got deleted and I hate wasting time on cleaning up wikicode, categorizing and sometimes adding files to other projects that eventually get deleted. --Jarekt (talk) 15:13, 17 August 2024 (UTC)[reply]
Good to know there is a template for this.
It's a bit odd to get lectured about uploaders using systems before they existed (or were used differently): Commons:Undeletion_requests/Archive/2024-08#File:SloopPartnership.gif_File:SloopProjectLogo.gif_(2). But then I guess the admins hadn't been around back then either. Enhancing999 (talk) 15:24, 17 August 2024 (UTC)[reply]
Sometimes it's hard to tell that the pictures were imported from other wikis. There doesn't seem to be a general categorization by that.
So the question if it may have been uploaded as "own work" gets even more complicated. Enhancing999 (talk) 09:38, 19 August 2024 (UTC)[reply]

Jarekt and Asclepias thnk you for checking. We have {{Grandfathered old file}} that should be fine for a file/permission from 2005. So unless the uploader is known to upload copyvios etc. then I do not think we should require a VRT now. If you would like to help check more files there are other pl.wikis listed at m:User:MGA73/GFDL files/Categories.

JWilz12345 also thank you for checking! And yes sadly FOP is a problem :-( --MGA73 (talk) 10:30, 17 August 2024 (UTC)[reply]

People by location

Which category to add or create to connect for example Category:LeBron James by location and other people by location? Eurohunter (talk) 21:57, 14 August 2024 (UTC)[reply]

@Eurohunter: There's Category:Sportspeople by location. It's a little obtuse but you might create Category:Sportspeople by name by location or something like that. --Adamant1 (talk) 04:27, 15 August 2024 (UTC)[reply]
@Adamant1: Yes, something like that, just I wasn't sure about the name for it. Eurohunter (talk) 08:36, 15 August 2024 (UTC)[reply]
Please nooo, burn this category tree down to the ground. Category:LeBron James by location (no files) -> Category:LeBron James in the United Kingdom (no files) -> Category:LeBron James in England (no files) -> Category:LeBron James in London (1 file).
That whole category tree only hides the files, instead of making them findable, although I still suspect that some people think that is the goal of categories. Multichill (talk) 16:37, 16 August 2024 (UTC)[reply]
Please don't do this. This is typical overcategorization. This is not how categories should be used, and part of the reason the category system is going to eventually fail for Commons. We have way too many categories already. Categories should not be used as a short description of the file. It’s not supposed to be a query language. —TheDJ (talk • contribs) 17:14, 16 August 2024 (UTC)[reply]
Please stop using the reserved term "overcategorization" for anything that is not defined in COM:OVERCAT. And «more categories per file than I’m somehow comfortable with» is not there, nor «categories more detailed than I think they should be», nor even «categories I don’t like». -- Tuválkin ✉ ✇ 11:11, 18 August 2024 (UTC)[reply]
There is bunch at Category:People_in_Washington,_D.C._by_name, Category:People in Australia by name. Any suggestions for a threshold in terms of number of images for individual's subcategories? Enhancing999 (talk) 10:47, 17 August 2024 (UTC)[reply]
I agree with DJ and Multichill that this category tree structure should not be used. "How many files do we allow before we diffuse the category?" None, the category should not exist. ReneeWrites (talk) 23:18, 17 August 2024 (UTC)[reply]
It's not a matter of diffusing, but of intersecting. Enhancing999 (talk) 11:17, 18 August 2024 (UTC)[reply]
Intersecting is one of the ways we diffuse.
If the intersection has near-null content, then it is usually not useful to add the intersection to the category tree, just use both categories on the file in question. All the more so if intersecting means a long chain of near-empty categories. - Jmabel ! talk 16:55, 18 August 2024 (UTC)[reply]
Well, intersection as a way of building it bottom up rather than (as done in the samples mentioned above, top down). If one creates a category "Joe Biden in the White House" below "Joe Biden", there is no need to start that with a category tree "Joe Biden in the Milky Way". Enhancing999 (talk) 09:32, 19 August 2024 (UTC)[reply]
@Enhancing999: not sure I see your point. You seem to be stating the obvious about not doing something ridiculous; is someone doing something you consider analogous to that? - Jmabel ! talk 18:18, 19 August 2024 (UTC)[reply]
Anyways, I looked into this after my initial comment and I mostly agree with other people here that these categories shouldn't be created unless there's enough images to justify it. For instance ones like Category:LeBron James in Texas are probably totally pointless. Categories names aren't meant to be stores of mundane, meaningless facts and that's all a category like that seems to represent. It would be totally ridiculous to similar categories for every sports person out there based on the country, state, city, or other location where they have played a random game. It's tangential, but the same goes for the accompanying Wikidata entry. --Adamant1 (talk) 10:35, 21 August 2024 (UTC)[reply]
I started a CfD for Category:LeBron James in Texas in case anyone wants to give their opinion about it and/or similar categories. --Adamant1 (talk) 10:41, 21 August 2024 (UTC)[reply]

August 15

How to delete metadata of a picture?

Hi. I can't find the procedure to delete/remove metadata of a picture.

Or should I nominate the photo for deletion and reupload it?

Cheers Shkuru Afshar (talk) 07:29, 15 August 2024 (UTC)[reply]

@Shkuru Afshar: What picture?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 09:24, 15 August 2024 (UTC)[reply]
Any
The pictures that I took but I forgot to delete the metadata before uploading. Shkuru Afshar (talk) 10:02, 15 August 2024 (UTC)[reply]
@Shkuru Afshar: You may overwrite instead. Which metadata is it important that you remove, and why?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:34, 15 August 2024 (UTC)[reply]
Thank you for your guidance. Because it is personal data. Shkuru Afshar (talk) 10:43, 15 August 2024 (UTC)[reply]
:@Shkuru Afshar: You can upload a new version without metadata and then request suppression of the original upload. - Jmabel ! talk 18:01, 15 August 2024 (UTC)[reply]
Thank you Shkuru Afshar (talk) 20:20, 15 August 2024 (UTC)[reply]
Where should I submit this suppression request? Shkuru Afshar (talk) 20:21, 15 August 2024 (UTC)[reply]
You could post it here, or COM:AN, but if you want to keep it confidential and it's not more than 10 or so files, feel free to email me the list and I will take care of it. - Jmabel ! talk 22:15, 15 August 2024 (UTC)[reply]
See also Commons:Requests for comment/Technical needs survey/Metadata editing tool. I think it would be good to enable people to easily quickly remove metadata (at upload and afterwards). This way the problem of false metadata from making it easily possible to change metadata would not arise. Prototyperspective (talk) 12:21, 17 August 2024 (UTC)[reply]
I've seen at least a few files where the person inserted their descriptions into the metadata for some bizarre reason. We should at least be able to edit the metadata in cases like that. Otherwise it would be to easy for someone to insert add copy or other pointless garbage into into it that we can't edit later. At least IMO we should be able to edit and change everything that's uploaded here regardless though. So the idea of us not being able to edit metadata just seems antithetical to this. --Adamant1 (talk) 09:48, 20 August 2024 (UTC)[reply]
Metadata (like that) is an integral part of the file. No matter the online tools provided, it essentially would still boil down to "download file, modify file, re upload file", just with a bit more of automation surrounding it (and a whole lot of expensive engineering required). I don't see it as a priority whatsoever. Nice to have definitely, but not critical. —TheDJ (talk • contribs) 11:32, 20 August 2024 (UTC)[reply]

POTY new rules

Dear users,

As you all know some featured pictures eventually end up being a Picture of the Year finalist. POTY scripts have been completely rewritten and I think a vote should be held to know it the rule stays "top 30 overall + top 2 of each category becomes finalist" or if, as proposed on POTY talk page by Ingenuity, it becomes "top 30 overall + top 5% of each category becomes finalist". Please vote on this page only.

Thank you for your time and I wish you all a beautiful day -- Giles Laurent (talk) 12:40, 15 August 2024 (UTC)[reply]

Fascinating, but the whole thing is a mystery to me. I guess for everybody else it's clear what the categories are and how many entries they have each. BTW I don't plan to vote there. Enhancing999 (talk) 06:52, 22 August 2024 (UTC)[reply]

August 17

Uploaded public transport photos - how to let people know they can use them in articles

Hello, just finished uploading of public transport photos from around the Europeː cs:Wikipedista:Penguin9/Moje fotogalerie MHD

Where I can let other Wikipedia users know they can use photos on Wikipedia articles if they find it good idea? Of course I can use photos in articles myself too.

Also, is there any quality check? If some photos will not be sufficient for Wikipedia, will I be asked to remove them to not flood Wiki with trash content?

Thank you very much on advanceǃ

--Penguin9 (talk) 00:23, 17 August 2024 (UTC)[reply]

You might want to look for a WikiProject that deals with transport and engage on the talk page. For example enwiki has en:Wikipedia:WikiProject Transport and cswiki appears to have cs:Wikipedie:WikiProjekt Doprava. Local to Commons there is Commons:WikiProject Transport, but it largely seems concerned with categorization. William Graham (talk) 02:14, 17 August 2024 (UTC)[reply]
To add to the above, I think one method is to categorize them well. Then the challenge would be to make these well-findable to editors via adequate WMC search engine sorting/functioning and increased awareness and use of article's corresponding WMC cat links which even editors relatively rarely visit. Editors may for example read an article and then think of an image that may be useful illustrating it and/or think it has too few images and subsequently go to WMC to check if there is a suitable image. Prototyperspective (talk) 12:25, 17 August 2024 (UTC)[reply]
I’m surprised you say that «article's corresponding WMC cat links »« even editors relatively rarely visit». In pt.wp all train station articles (and most of the others) link to the caregory here by means of pt:Template:Commonscat and I know I use it a lot to improve articles (because of course) but I also have proof that other editeors do it too, even editors with scarce or null past history of editing transport-related articles. Not saying is cannot be improved, but it’s no so bad. -- Tuválkin ✉ ✇ 11:08, 18 August 2024 (UTC)[reply]
It's not specific to public transport categories but most WMC categories have very few pageviews which was mostly what I was referring to. For example the major and important category Category:Sustainable transport, including many potentially useful illustrative or informative media, got a mere 7 pageviews the last 30 days which is so low it's hard to believe. There are probably many causes for this including:
  1. bad indexing by search engines like DuckDuckGo and Google (they rarely show WMC cats and do not show videos on WMC in their Videos tab or most images in their Images tab)
  2. no facilitation of users to explore the corresponding categories for example by enabling showing more related media for an article in the Wikipedia app or having a tile in its Explore feed for media related to current news items' articles
  3. the currently common practice of burying the link to the corresponding WMC category into the External links section put below, an often large, section of references that barely anyone clicks even if they scroll below the References section at all
Prototyperspective (talk) 11:22, 18 August 2024 (UTC)[reply]
If an image is categorized, you could always visit the corresponding WP articles and check if it's worth adding suitable ones from the category in these articles.
  • if the language uses an infobox and that one doesn't have an image, I'd try to add a suitable one.
  • if the article is already illustrated, I wouldn't touch it unless the images are clearly not particularly useful and better ones are available. Sometimes an article's images reflect what was available when the article was written 15 years ago and Commons has much more to offer since.
  • bear in mind that different Wikipedia versions have different standards on how to illustrate articles (and views of contributors differ as well).
  • obviously: avoid adding "your" image to every to conceivable article
  • it can be worth mentioning a suitable image on an article's talk page, especially if you don't know the language or aren't confortable with it.
  • specifically for vehicles, some languages have lists of those: check if these can be completed.
Maybe you want to add a copy of your user gallery at Commons as well. It's more likely to be found than at a Wikipedia. Enhancing999 (talk) 11:39, 18 August 2024 (UTC)[reply]
@Penguin9: I wouldn't worry about the quality issue; your pictures are very good. That said, it would be nice to have them at higher resolution. Can you do that? You can make your images more findable by adding English descriptions (some have them, but others, such as File:Ostrava, Solaris Trollino II 12 AC č. 3728 a Škoda 36Tr TEMSA č. 3744.jpg do not. Consider adding categories by date and for the camera used; as well as more descriptive categories such as "Blue trolleybuses" and "Buses at night" (Ive categorised the above image, by way of an example). You could create and apply Category:Images by Penguin9 (or use your real name if you prefer, like I do). You might also nominate some of your pics for good picture status. And, while it is correct to say you should not "add 'your' image to every to conceivable article", you can look for relevant articles with no image and add them there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:35, 18 August 2024 (UTC)[reply]
Most of photos have about 4000px on bigger size, you just have to open the picture.
About using real name - I would like to, but photos have already nick there and I do not want to edit it for every photo separately. Penguin9 (talk) 17:22, 18 August 2024 (UTC)[reply]
There are automated tools to make the mass edit easy if you wish to do so. See Help:VFC, for example. --Geohakkeri (talk) 17:47, 18 August 2024 (UTC)[reply]
For Wikipedia, it can be more important that a picture includes one or the other feature than the general photographic qualities of the picture. Enhancing999 (talk) 09:29, 19 August 2024 (UTC)[reply]

Mention of overwriting cases at COM:FLICKR

COM:FLICKR currently does not have a section discussing the possibility of Flickr uploaders changing or overwriting their images on Flickr (which is permitted on the site). For example, File:Butanding Whale Shark (Donsol, Sorsogon) (794278440).jpg vs. this (which the file description points to as the source). While the CC licensing is widely-considered "irrevokable", it is better worth-mentiong the overwriting case in the policy page regarding Flickr imports. JWilz12345 (Talk|Contrib's.) 05:31, 17 August 2024 (UTC)[reply]

Even trivial edits to files there can lead to duplicate imports here. Enhancing999 (talk) 09:41, 19 August 2024 (UTC)[reply]

Discussion about Template:Keep local on enwiki

Hello, just a notice that I have started a discussion to prevent use of "Keep local" template for files which are not fully or partly own work. You are welcome to join in. —Matrix(!) {user - talk? - uselesscontributions} 06:36, 17 August 2024 (UTC)[reply]

August 18

Intentional footprints

is there a better category than Category:Shoeprints in art for these "intentionally created real or fake footprints intended to guide people"? RZuo (talk) 20:30, 18 August 2024 (UTC)[reply]

There's some similar images in Category:Signs on floors. What about creating Category:Shoeprint signs on floors? --Adamant1 (talk) 20:54, 18 August 2024 (UTC)[reply]
I support that idea. ReneeWrites (talk) 21:21, 18 August 2024 (UTC)[reply]
I like that idea too! -- Tuválkin ✉ ✇ 17:34, 19 August 2024 (UTC)[reply]

Which Stena line ship?

Unfortunatly I did not keep the boarding tickets and I cant remember the ships name. Frederikshavn to Goteburg. I can look up the ships name when you book, but is there a website to look up the ships sailing on 12 july?Smiley.toerist (talk) 21:48, 18 August 2024 (UTC)[reply]

@Smiley.toerist: I don't suppose you could ask the travel agent / booking agent / ship operating company?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 23:50, 18 August 2024 (UTC)[reply]
I found the reservation with the departure time of 12:15 on my mobile phone but no mention of the ships name. The travel agent / booking agent / ship operating company has information about the the future sailings with ships names, but not the historic sailings in the past. Try to get the past shedule for July 12th on https://www.stenalinetravel.com/routes/frederikshavn-gothenburg. I suspect the Stena Danica, but no certainty as Stena Lines has many ships. https://www.stenalinetravel.com/ferries. Smiley.toerist (talk) 09:22, 19 August 2024 (UTC)[reply]
@Smiley.toerist: Per https://www.stenalinetravel.com/routes/frederikshavn-gothenburg , Stena Lina has only three ferrys on the Frederikshavn-Gothenburg route: Stena Danica, Stena Jutlandica, and Stena Vinga. Luckily, for identification purposes, the three are very different ships, so you should be able to identify your ship by comparing to other photos of the stern area. Did you travel by foot / did the ship accept foot passengers? If yes, then it can't be the Stena Vinga, as per the Stena information page, it is "only for passengers traveling by vehicle". So you would be left with either the Stena Danica or Stena Jutlandica. Gestumblindi (talk) 08:51, 20 August 2024 (UTC)[reply]
If I extrapolate this to 12 July 12:15 I get Stena Danica Ymblanter (talk) 09:01, 20 August 2024 (UTC)[reply]
(note that the schedule currently goes back to Jul 21) Ymblanter (talk) 09:02, 20 August 2024 (UTC)[reply]
After some inspection, I think you're right that it must be the Stena Danica. This is the stern of the Stena Jutlandica - completely different. Gestumblindi (talk) 08:54, 20 August 2024 (UTC)[reply]
It could not be Stena Jutlandica as I took this picture of this ship going in the other direction. Theoreticaly it could be stil another ship before jul 21, but it is unlikely they would change the ships used for the ferry line. (they only use two ships).Smiley.toerist (talk) 16:52, 20 August 2024 (UTC)[reply]

August 19

Showing wrong text for {{Diffusion by condition}} and {{CatDiffuse}}

At least in Dutch the wrong text is shown when {{Diffusion by condition}} and {{CatDiffuse}} is used, see for instance Category:Aba (clothing) for the first and an earlier version for the second. This category should not have no files at all, it is just that over 500 is too many. This text looks to be meant for main or "by" categories. I have no idea where I can find the text or how to solve this problem. Perhaps someone whith knowledge of templates?--JopkeB (talk) 10:10, 19 August 2024 (UTC)[reply]

@JopkeB: I think you're looking for this: Template:CatDiffuse/nl ReneeWrites (talk) 14:15, 19 August 2024 (UTC)[reply]
Thanks ReneeWrites, that is indeed the text. And it has not been changed for 15 years and the English text is the same. So either I had other expectations of the text or something else is going on. JopkeB (talk) 15:34, 19 August 2024 (UTC)[reply]

Improvements to "Use this file" facility

A change I requested a year ago has just been deployed. Now, when a user viewing a file description page selects "Use this image", the markup is pre-populated to use the image's caption, rather than the filename, as the displayed text.

For example, for the image File:Aris’s Birmingham Gazette - 1771-11-11 - p1.jpg - the markup previously returned for "use this file on a wiki" was:

[[File:Aris’s Birmingham Gazette - 1771-11-11 - p1.jpg|thumb|Aris’s Birmingham Gazette - 1771-11-11 - p1]]

but now it is:

[[File:Aris’s Birmingham Gazette - 1771-11-11 - p1.jpg|thumb|front page masthead of Aris’s Birmingham Gazette, 11 November 1771 edition]]

This change also applies to other code snippets generated by the tool, such as for embedding an image on an external site.

The text returned is in the user's preferred language, where available.

Please report any issues at MediaWiki talk:Gadget-Stockphoto.js.

Yet another reason to add captions to your uploads, and translate them on others'! Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:15, 19 August 2024 (UTC)[reply]

That's a useful change. Two issues:
  • I think when there is no caption it should use the file description in some way (e.g. only in most cases when the description is not very long and/or only the first paragraph)
  • Instead of spending lots of time translating captions of any of the 100 million files into 300 languages (100 M × 300 and the number of files in use is also not small), I think that should be done using machine translation which works very well at this point for many languages for short phrases like those in captions (which if necessary could still be adjusted and get automatically updated if and once the source caption gets changed).
Prototyperspective (talk) 12:25, 20 August 2024 (UTC)[reply]

Cactus expert needed

At [2] (on Wikispecies), the identity of the cactus depicted in File:Oreocereus fossulatus rubrispinus 3.jpg (and by extension et seq) is disputed by User:MrtnLowr.

The category Category:Oreocereus fossulatus is linked to 'Category:Oreocereus fossulatus' (Q55275655), but the infobox on the category displays "Oreocereus pseudofossulatus".

There is also discussion at Talk:Valued image set: Oreocereus pseudofossulatus

Please can someone review all this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:42, 19 August 2024 (UTC)[reply]

Notifying Stan Shebs. -- Asclepias (talk) 12:17, 19 August 2024 (UTC)[reply]

August 20

Category:Military units and formations of the British Army

Almost a year has gone by and no one has addressed a question I asked at Category talk:Military units and formations of the British Army. The text on this category page does not make sense to me, can someone else please have a look and see if you can understand it? - Jmabel ! talk 03:50, 20 August 2024 (UTC)[reply]

Keep which

2,400 × 1,600 pixels, file size: 1.74 MB Software used Adobe Photoshop CS3 Windows

5,616 × 3,744 pixels, file size: 670 KB Software used Adobe Photoshop CS5 Windows

it seems User:Baitaal exported the photo twice differently. judging from the resolution, i guess we should keep the 5,616 × 3,744 pixels one? RZuo (talk) 07:36, 20 August 2024 (UTC)[reply]

Yeah, it's higher resolution and it's in use. ReneeWrites (talk) 07:50, 20 August 2024 (UTC)[reply]
NO please keep the 2'400 × 1'600 pixels version loading faster and having more detail. Taylor 49 (talk) 16:54, 21 August 2024 (UTC)[reply]
I see no sense in which the lower-res image has more detail, and at any given resolution that the lower-res one can provide, they should download at the same speed. - Jmabel ! talk 17:45, 21 August 2024 (UTC)[reply]
The seemingly bigger image (higher x, higher y, higher pixel area) has substantially less data. When loading the 5'616 × 3'744 pixels image, your computer has to hog memory (ca 60 MiO) for the huge pixelmap, decompress the data generating mostly noise (JPG is lossy), and subsequently zooom down the huge pixel area (assuming that your screen does not provide a height over 5'616 pixels). The seemingly bigger image has absurdly many pixels that however do NOT hold any image information. You could zooom up the 5'616 × 3'744 image by factor 10 getting a 56'160 × 37'440 image, would it be even better? Try it! Taylor 49 (talk) 21:53, 21 August 2024 (UTC)[reply]
Unless you specifically click through to the full-res image, you don't download the full resolution to your computer. The bulk of the downscaling is done server-side, making a thumbnail of one or another size. - Jmabel ! talk 23:00, 21 August 2024 (UTC)[reply]

No error message for same file names in Upload Wizard

The Upload Wizard is not displaying any useful warning message for same file names, instead throws an error message and not letting the user publish files.

"There is one error with the forms above. Correct the error, and try submitting again."

Phabricator: https://phabricator.wikimedia.org/T372860 Saiphani02 (talk) 09:00, 20 August 2024 (UTC)[reply]

Help needed cleaning up Category:Media from Telegram

Hello. I added all files with a source from Telegram to this category. A bunch of images are copyright violations and I can't review them all. If somebody wants to help cleaning up, you're more than welcome to! Cryptic-waveform (talk) 21:46, 20 August 2024 (UTC)[reply]

@Cryptic-waveform: so shouldn't we also have a Category:Media from Telegram to be checked, which people can remove after validating PD or a free license? Otherwise, this is just asking tons of people to look over-and-over at the same files. - Jmabel ! talk 03:18, 21 August 2024 (UTC)[reply]
Good point. ✓ Done. Cryptic-waveform (talk) 11:15, 21 August 2024 (UTC)[reply]

August 21

Photo challenge June results

Mushrooms: Entries • Votes • Scores
Rank 1 2 3
image
Title Poisonous mushrooms
against a forest in
autumn, Wrzosów, Poland		 Mycena interrupta NZ
Author Ivonna Nowicka Famberhorst Haydenrjones
Score 15 13 9
Construction sites: Entries • Votes • Scores
Rank 1 2 3
image
Title Carpenter working
on a concrete formwork		 Workers attaching
a chain to the Main
bridge in Ebing		 Demolition site of
the so-called Kaufhof store
"Tortenschachtel" (cake box)
on Berliner Platz
Author Ermell Ermell F. Riedelio
Score 17 14 11

Congratulations to Ivonna Nowicka, Famberhorst, Haydenrjones, Ermell and F. Riedelio. -- Jarekt (talk) 03:33, 21 August 2024 (UTC)[reply]

Pulling cords

Is there a category for these signal cords? In many old trams it used to be the norm and buttons where not used.Smiley.toerist (talk) 10:06, 21 August 2024 (UTC)[reply]

@Smiley.toerist: Category:Emergency stop pull cords?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:14, 21 August 2024 (UTC)[reply]
I'm kind of surprised Category:Stop pull cords doesn't exist. I'd probably create it if we're me though since these cords aren't technically used for emergencies. @Smiley.toerist: BTW, your documentation of the more minor things related to public transportation like these cords is really interesting. I'd probably work on a similar project if I traveled more and wasn't worried about being doxed. --Adamant1 (talk) 10:22, 21 August 2024 (UTC)[reply]
For example, File:Lisboa_071DSC_0275_(49068453986).jpg is in Category:Bus bells. I guess it’s the closest to Category:Stop pull cords we’ve got. --Geohakkeri (talk) 10:48, 21 August 2024 (UTC)[reply]
@Geohakkeri: Yes, bus bells makes more sense for those photos, but the purpose of the bells on buses (stopping the bus at the next stop) should be in the topic, right? I've seen similar cords for declaring an emergency (necessitating a stop) on trains, and similarly-purposed touch-sensitive yellow tape and red stop buttons on more modern buses (the latter at rear exits).   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:59, 21 August 2024 (UTC)[reply]
Not always a stop signal: On the Belgian vicinal railways the conductor pulled on the cord twice (ding ding) to signal that the tram is ready to leave. By the way: on small boats there is a safety cord to the outboard motor, so if the person with the cord falls in the water, the outboard motor automaticaly switches off.Smiley.toerist (talk) 13:10, 21 August 2024 (UTC)[reply]
I created: Category:Stop pull cords. There must be other examples.Smiley.toerist (talk) 09:27, 22 August 2024 (UTC)[reply]
I filled in the categories. There where some misplaced Tram stop pull cords in Category:Bus bellsSmiley.toerist (talk) 12:02, 22 August 2024 (UTC)[reply]
@Smiley.toerist: If pulling the cord rings the bell and both are pictured, shouldn't the file be in both categories?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:06, 22 August 2024 (UTC)[reply]

Who painted this?

On this webpage there is a painting, rendered in black-and-white, attributed to Jan van der Straet. But is it really by him and painted in his time (16th century)? The style looks different, more modern. His 16th century paintings are typically filled with detail without much perspective, but here only the lower half of the painting contains people and detail, and the upper half is sky, trees and distant landscape. So who painted this? Can we find the painting (in colour)? --LA2 (talk) 13:31, 21 August 2024 (UTC)[reply]

Looking for page about having an account

I recently suggested to an anon ip editor that they log in and get an account. I was going to link to a page about that, but looking around I failed to find such. I see Commons:First_steps/Account which is for someone who has already decided to start an account and takes them through setting one up step by step. I see Commons:Welcome which says "Our first steps help file and our FAQ will help you a lot after registration." The issue is we have many editors who have never gotten as far as registering. I was looking for something with basic explanation of what an account is, and why one might wish to start one, similar to en:w:Wikipedia:Why create an account?. Do we have anything like that here? If we do, it needs to be more easily found. If not, I rather think we should; is there any counter-argument that we shouldn't? -- Infrogmation of New Orleans (talk) 15:00, 21 August 2024 (UTC)[reply]

I think it would be fine to have our own rework of en:w:Wikipedia:Why create an account?, or just to refer people there and say that the situation is basically the same. - Jmabel ! talk 17:48, 21 August 2024 (UTC)[reply]
It's a bit more obvious here than at Wikipedia .. uploads require one. Not sure if there is much to do without one. Enhancing999 (talk) 06:48, 22 August 2024 (UTC)[reply]

Username renaming

Current Username: BeastyJaguarCupcake40

Requested New Username: TheCoolPinata22

Reason for Change: I would like to change my username to TheCoolPinata22 for personal preference reasons. The new username aligns better with my online identity and interests.

Please let me know if any additional information is required.

Thank you,
TheCoolPinata22 discuss with me! 15:58, 21 August 2024 (UTC)[reply]
You have to make a request at m:Steward requests/Username changes. GPSLeo (talk) 16:04, 21 August 2024 (UTC)[reply]
Simple global rename requests belong to m:Special:GlobalRenameRequest. "personal preference reasons" are OK. Taylor 49 (talk) 16:50, 21 August 2024 (UTC)[reply]
Why TheCoolPinata22 discuss with me! 16:54, 21 August 2024 (UTC)[reply]
Well, SRUC is also a valid venue. If your rename request is simple, you have two options… --Geohakkeri (talk) 17:29, 21 August 2024 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. --Prototyperspective (talk) 20:13, 21 August 2024 (UTC)

Is this a breach of copyright?

The file [3] has a description that is a copy of the museum's website description at [4]. ThoughtIdRetired (talk) 16:27, 21 August 2024 (UTC)[reply]

Simple enough that it is probably not copyrightable except maybe the last sentence. - Jmabel ! talk 17:50, 21 August 2024 (UTC)[reply]

Boots

anyone knows the difference between the two? File:Fuel Girl breathing fire at International Brussels Tattoo Convention 2023.jpg is which boot? RZuo (talk) 17:38, 21 August 2024 (UTC)[reply]

Thigh-high boots are a subcategory of over-the-knee boots. Both cover roughly the same area (physically) but thigh-highs are a more modern type fashion boot that's usually worn by women and commonly associated with fashion and fetishism, whereas over-the-knee boots (a much older term, originating in the 15th century to describe riding boots worn by men) cover all kinds of boots including e.g. working boots worn by farmers.
The image you linked is of a woman wearing thigh-high boots. ReneeWrites (talk) 22:49, 21 August 2024 (UTC)[reply]

Uploading larger files

I'm trying to crop File:1968 LINCOLN PARK DEMONSTRATIONS DURING DEMOCRATIC NATIONAL CONVENTION 111-lc-53312.webm, a 518 MB file. Is there a user right that allows me to upload larger files? The crop is now 494 MB, but still much larger than the limit of 100 MB. SWinxy (talk) 22:35, 21 August 2024 (UTC)[reply]

See Help:Chunked upload. --Geohakkeri (talk) 22:39, 21 August 2024 (UTC)[reply]

August 22

Depicts

I am continually dealing with dubious "depicts" added to files I've uploaded. I've repeatedly remarked on them at Commons talk:Depicts, but really no one has engaged my remarks there, so I'm here pointing to that page.

When one of these dubious edits has an edit summary that says, "#suggestededit-add-tag 1.0", does that mean there is a bot out there somewhere actively suggesting these bad edits? Does anyone know what bot? - Jmabel ! talk 00:29, 22 August 2024 (UTC)[reply]

@Jmabel: This is one of the Growth/Personalized first day/Newcomer tasks aimed at fostering the growth of newcomers.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 05:19, 22 August 2024 (UTC)[reply]
Do you know where to find the interface the users get for this specific task? On Commons the extension is not enabled and on dewiki where I tested it a bit I do not get these image tagging task. GPSLeo (talk) 05:55, 22 August 2024 (UTC)[reply]

I'm hoping to find appropriate categories for File:Helix, v.4, no.4, Aug. 15, 1968 - DPLA - ed4ee91948fc8a79b182fdeb295370d3 (page 8).jpg and File:Helix, v.4, no.4, Aug. 15, 1968 - DPLA - ed4ee91948fc8a79b182fdeb295370d3 (page 9).jpg: photos related to a U.S. Army Sp/4 who was arrested after going AWOL during the Vietnam war and seeking sanctuary in a Seattle church. I'm not finding a lot that covers the case. - Jmabel ! talk 00:37, 22 August 2024 (UTC)[reply]

Is renaming categories with an English name to local language names a good idea?

Category:Heroes' Cemetery in the Philippines has been renamed to Category:Libingan ng mga Bayani, to "match Wikipedia and Wikidata", see history of this category. Though there are exceptions for English category names: "some proper names, ... and names for which the non-English name is most commonly used in the English language" (see Commons:Categories#Category names), I wonder whether such an exception applies to this category and whether this would be a good development for other category names that are now in English but might have other names in Wikipedia and Wikidata. Because I can understand the English name without a translation program, but not the name in Philippine (or the majority of other languages). @Seav: Can you give your opinion as well? JopkeB (talk) 05:43, 22 August 2024 (UTC)[reply]

If there is a Category Redirect, I see no problem. There is a problem with English names that are meaningless to local people. Like Our Lady of the Forsaken, that is a very common thing to find around my place, that means absolutely nothing to the Valencian local people, who are enterly familiar with either la Virgen de los Desamparados or la Mare de Déu dels Desemparats. I do use English category names, but I have to explain my wife once and again what is Our Lady of Good Health (la Virgen de la Salud) or Saint Anthony the Great (Sant Antoni del Porquet).
I think a more multilingual approach is required. B25es (talk) 05:55, 22 August 2024 (UTC)[reply]
Then I would prefer to have the redirect the other way around: let the English name be the category name and let the local name have the redirect. JopkeB (talk) 06:11, 22 August 2024 (UTC)[reply]
Hi! Thank you for bringing this topic up. I think the relevant policy is Commons:Language policy, which defers to a section: Commons:Categories#Category names. As you have stated, the important passage is:

Category names should generally be in English (see Commons:Language policy). However, there are exceptions such as some proper names, biological taxa and names for which the non-English name is most commonly used in the English language (or there is no evidence of usage of an English-language version).

I think my rename follows the "proper names [...] for which the non-English name is most commonly used in the English language". The English Wikipedia article title, Libingan ng mga Bayani, had been discussed and renamed a few times since 2009 between the English-translated name and the official native-language name (see the header on Talk:Libingan ng mga Bayani), with the latest move request in 2020 resolving to the native-language title. There is plenty of evidence that the native-language name is used in English-language sources (albeit sources in the Philippines, but then again, English is an official language of the country). Some examples of English reliable sources within the past year that use the native-language name: [5][6][7][8].
I consider this situation similar to categories like Category:Taoisigh which could be reasonably be actually named Category:Prime ministers of Ireland, but we're using the Irish name here in Commons (so far without any argument, I think?) and also in the English Wikipedia (w:Taoiseach). —seav (talk) 06:14, 22 August 2024 (UTC)[reply]
"Taoisigh" is apparently not a proper name of a person, like Mary Johnson, but the name of a function, in the rest of the world known as "Prime minister". So this is not part of the exception. AND it is clearly not conform the Universiality principle, which says that "Identical items should have identical names for all countries and at all levels of categorization." So, please make the redirect the other way around. JopkeB (talk) 08:43, 22 August 2024 (UTC)[reply]
 Oppose Changing the name to the "native-language" for two reasons
  • 1. The idea that it's in the "native-language" now is totally ridiculous to begin with. According to Google 22.5 million people in the Philippines speak Tagalog. While 39.4 million speak English. Further the place being discussed here is a national cemetery within Fort Bonifacio. The national headquarters of the Philippine Army. So it's just more likely due to how many speak English then Tagalog nationally that they will speak English. Meaning the change will clearly reduce the number of people who will be able to find the category. I don't think it's simply enough to simply have a redirect in this case either. Otherwise you could justify renaming every category to the "native language" simply because redirects exists. That's not their purpose. Per the guidelines we have to go with the name whatever language has the most chance of being searched for and it's pretty clear that's English in this case.
  • 2. There's been multiple CfDs having to do with this exact issue in the last couple years and there was clearly no consensus from them to change the names of the categories to the "native-language" at the time. I highly doubt if Seav had pf started a CfD for this before changing the name that it would have gone anywhere. That's what they should have done instead of just unliterally changing the name based purely on how the place is named on Wikipedia. Regardless, it's pretty clear that there is no consensus to use "native-language" names for categories in cases like this one. I'm not sure what the circumstances around Category:Taoisigh versus Category:Prime ministers of Ireland, but "other stuff" isn't really a valid reason to make the change. Again, especially considering the outcome of prior CfDs, guideline, and fact that clearly more people speak English in the Philippines then Tagalog and this is the national headquarters of Philippine Army. It would be ridiculous to say that shouldn't matter "because Wikipedia article." --Adamant1 (talk) 06:37, 22 August 2024 (UTC)[reply]
Do we have a reference for the English name or is it just a literal translation? File:2551Taguig City Landmarks 17.jpg is in English. Enhancing999 (talk) 06:43, 22 August 2024 (UTC)[reply]
In English the name literally translates to "Cemetery of (the) Heroes" (libingan = cemetery; mga bayani = heroes). I've seen that translation (with or without the definite article) and I've seen the variation "Heroes' Cemetery" as well. A couple more points: the official website of the cemetery is [9], which is in English but still uses the native-language name, and the law that established the cemetery is Proclamation No. 208, s. 1967, also in English, but the name is again the native-language name. —seav (talk) 07:03, 22 August 2024 (UTC)[reply]
 Oppose renaming but see meta:Community Wishlist/Wishes/Add machine translated category titles on WMC. Prototyperspective (talk) 09:19, 22 August 2024 (UTC)[reply]

Origin of locations in infoboxes

Does anyone know where the infoboxes get their information for the location of a place from? As an example, Category:Ranský rybník has an infobox that says it's located in "Czechia." Although looking at everything related to it the country seems to be called "the Czech Republic." Even on Wikidata's end. So it's not clear to me where exactly "Czechia" is coming from in the infobox. Any ideas? Adamant1 (talk) 10:11, 22 August 2024 (UTC)[reply]

@Adamant1: From Wikidata, via Template:Wikidata Infobox. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:22, 22 August 2024 (UTC)[reply]
I think the question is why it says "Czechia" when the wikidata item has "Czech Republic" set. Prototyperspective (talk) 10:30, 22 August 2024 (UTC)[reply]
Pinging @Mike Peel.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:32, 22 August 2024 (UTC)[reply]
My guess is that it uses Module:WikidataIB for printing location string which uses short name (P1813) if it is defined for the language. --Zache (talk) 11:15, 22 August 2024 (UTC)[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&oldid=914560751"