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? 41 25 RobbieIanMorrison 2024-08-23 17:06
2 Further dissemination of Wikimedia Commons Atlas of the World needed 54 9 Adamant1 2024-08-29 03:11
3 Add "Upload file" link for mobile? 25 12 Nakonana 2024-08-28 12:36
4 Flickr2Commons 29 10 A1Cafel 2024-08-27 16:02
5 POTY new rules 3 2 Enhancing999 2024-08-24 10:05
6 Pulling cords 10 4 Smiley.toerist 2024-08-22 21:37
7 Who painted this? 2 2 Broichmore 2024-08-24 12:38
8 Looking for page about having an account 5 3 Enhancing999 2024-08-22 20:14
9 Uploading larger files 3 2 SWinxy 2024-08-22 23:14
10 Depicts 4 3 Jmabel 2024-08-22 18:29
11 Categories related to war resisters 9 3 Una tantum 2024-08-27 17:18
12 Is renaming categories with an English name to local language names a good idea? 42 13 Jmabel 2024-08-27 00:25
13 Marking with NowCommons 6 3 MGA73 2024-08-25 13:25
14 Category:Videos by subject 10 4 Prototyperspective 2024-08-27 16:52
15 Sign up for the language community meeting on August 30th, 15:00 UTC 1 1 MediaWiki message delivery 2024-08-22 23:18
16 Uncategorized categories again 12 7 Jmabel 2024-08-25 18:38
17 {{Large image}} 6 4 Bawolff 2024-08-28 17:15
18 Promotional material in image description? 5 4 PantheraLeo1359531 2024-08-24 16:17
19 Crop Tool, again 9 4 Wouterhagens 2024-08-28 18:58
20 Fix for mobile description table 4 3 Lucas Werkmeister 2024-08-24 11:49
21 Rename ship 7 4 Jmabel 2024-08-27 19:21
22 Category subtree Category:Floor plans of churches by country 6 3 Jmabel 2024-08-25 18:45
23 Can I upload bt2020nc/bt2020/smpte2084(PQ) HDR AVIF images to commons and use them in wikipedia articles? 4 2 PantheraLeo1359531 2024-08-27 06:07
24 Signature on Japanese woodblock 8 6 Adamant1 2024-08-27 03:16
25 Debugging screenshots 12 4 Klein Muçi 2024-08-28 08:18
26 JPEGs versus PDFs for multipage scans 5 5 Samwilson 2024-08-27 11:34
27 How to handle poorly-created gallery pages that are the main target of the interwiki links? 36 13 JopkeB 2024-08-29 03:50
28 Thank you to all the 2024 Summer Olympics photographers! 3 3 Kyah117 2024-08-27 21:38
29 Massive backlogs are now the norm 24 12 JopkeB 2024-08-28 06:36
30 Category for "buses in" and "buses of" 9 3 Infrogmation 2024-08-28 20:52
31 Reredos or reredoses? 2 2 Jmabel 2024-08-28 00:36
32 Toilet type 2 2 Adamant1 2024-08-27 22:52
33 Is File:P103013PS-0384 (10596687253).jpg actually PD? 2 1 Jmabel 2024-08-28 00:44
34 Uncategorized categories, except infobox 15 2 Prototyperspective 2024-08-28 22:37
35 Wikimedia Foundation Board of Trustees Election - Introduction 2 2 Jmabel 2024-08-29 03:47
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.
Old manual pump in Fetonte Place Crespino, province of Rovigo [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, png, or webp, 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]
Some more nuanced guidance is also needed. In some corner cases, uncompressed TIFF plus suitably converted JPG, duly linked across the two uploads, is the optimal answer. But to my knowledge, you will not find that advice provided. Keep it simple stupid (KISS), as a communications philosophy, has its limitations too. (Sorry, but I am not offering to write documentation — my list of images to process and upload is already too long.) RobbieIanMorrison (talk) 19:14, 22 August 2024 (UTC)[reply]
Just to continue, there may be occasions when uploading the RAW file from the camera in parallel would also be indicated. Not often though, but should still be covered in the documentation as an option. RobbieIanMorrison (talk) 17:06, 23 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]
Its only really nescessary on the english version, as that is the reference focus, if not the definitive article. Broichmore (talk) 12:14, 23 August 2024 (UTC)[reply]
 Comment For a better navigation: I have started a discussion to make it a rule that always a gallery category should be added to a gallery page, see Commons talk:Galleries#Proposal to add always a Gallery category to a gallery page. I invite you to join this discussion as well. --JopkeB (talk) 15:41, 25 August 2024 (UTC)[reply]

Conclusions so far + open questions

The Question was: Can the gallery page Wikimedia Commons Atlas of the World get more attention, for example on the Main page? The links to important (root) galleries can serve as a starting point to continue navigating gallery pages, just like Featured and other good pictures are mentioned under "Highlight" on the Main page. Another possibility is to restructure the "hidden" categories on the main page, under Content/By type, to make them more visible.
Though the main focus of this discussion was on gallery pages in general:

  • A gallery page can show more than Wikipedia or other wikis can do and so gallery pages are potentially very valuable, but they are tremendously underutilized. They can help to present images in a category in a structured way, or to focus in the most important ones.
  • But too many galleries:
    • are poorly developped (have only one or a few images or only replicates a category) and/or
    • need an update (solution: perhaps we can mark such a gallery page with something like: This gallery page needs some TLC) and/or
    • lack scope, a clear purpose, direction, and/or a theme.
  • Another problem is navigating galleries.
  • Perhaps we can revive Commons:Featured galleries, to encourage improving gallery pages. Still to be discussed: what are criteria for a good gallery page?
  • Another suggestion: create a guideline beyond Commons:Galleries that lays out what makes a "good" gallery and provides some standard for them. But then again: what are good standards?

Still open:

  1. How can the Main page be restructured to make useful galleries like Wikimedia Commons Atlas of the World more visible? Please make a proposal and discuss it on Talk:Main Page.
  2. Create more galleries for navigating like Wikimedia Commons Atlas of the World. For which subjects should they be made?
  3. What are good standards for galleries in general? They might be added to Commons:Galleries (after a discussion on its Talk page) or included in a new guideline.
  4. What are criteria for a good gallery page? To be discussed on Commons:Featured galleries.

@MGeog2022, Enhancing999, Adamant1, Jmabel, Enyavar, Broichmore, Sbb1413, and Jeff G.: Do you agree with the conclusions? Do you have other questions still to be answered? Do you have answers to the questions? --JopkeB (talk) 08:48, 27 August 2024 (UTC)[reply]

A few thoughts on my side:
1. I think having a "featured galleries" thing on the main page would help make them more useful. Having a list of galleries on the side of the page is perfectly fine, but I suspect most people don't use it or find things that way on here to begin with.
2. I'm not a big fan of so called "navigational galleries" because they come off to much like half baked Wikipedia articles or something. I'm not really sure, but it kind of defeats the purpose of the whole thing when 99% of a gallery is text so people move to other galleries. It's just overly convoluted and galleries aren't meant to be navigational pages anyway. Galleries should just be categorized better.
3. Good standards for galleries should really be figured out in it's own separate discussion. I totally support figuring it out and creating another page outside of Commons:Galleries that lays things out related to the proper creation of galleries though. One of the ways that good galleries can and will be become useful/visible is by getting rid of or improving the bad ones. It's kind of pointless to list or feature galleries on the main page when most of them are junk though. So say like 4 or 5 of us should get together, go through the current galleries to categorize them and nominate the clearly bad ones for deletion. Then we can go from there? I'm not sure it would be good or doable to create a standard for good galleries without knowing what currently exists more broadly or having them properly organized though. It's kind of putting the cart before the horse to a degree. --Adamant1 (talk) 15:06, 27 August 2024 (UTC)[reply]
@Adamant1: @3. Good ideas. I would like to join that discussion. Where can we have such a discussion? For me it would be OK to have it on Commons talk:Galleries and finally put the conclusions on Commons:Galleries; then everything you want to know about galleries, is on one page. Do you have a better idea? JopkeB (talk) 09:19, 28 August 2024 (UTC)[reply]
@Adamant1, @JopkeB, I agree that having "featured galleries" linked from main page would be a good thing. In addition, root pages of "systems of galleries" for maps (Atlas of the World), for any kind of media about places (the existing galleries about countries, and then country subdivisions or cities in them, with some home page providing access to all of them through links in one form or another), art (galleries about paintings, sculpture etc, again with a home gallery page linking to the others).
Those "systems of galleries" would be linked from main page, not because of their high quality (while it is desirable they have high quality, though), but because they are some kind of "project" themselves: an Atlas, an "art museum" (let's call it so), etc.
Galleries with an exceptional quality would be included in Featured galleries, and a link to a page that links to each one of them would be included in Commons main page (all in exactly the same way it's done for featured pictures). For example, Chronologic old maps of Paris could probably be a featured gallery, but it would never be the root page of a "system of galleries" (but it could pontentially be part of one of such systems). MGeog2022 (talk) 18:04, 28 August 2024 (UTC)[reply]
By the way, we have this proposal to vote on linking Atlas from main page (to avoid duplicating discussions). MGeog2022 (talk) 18:06, 28 August 2024 (UTC)[reply]
Just to clarify, I don't necessarily have an issue with root pages of a "system of galleries" per se. But if they are going to be in the gallery space, then they should be also be galleries themselves. Otherwise it just goes against their purpose. At the end of the day we should probably have a special sub-domain or something for pages that purely or mainly serve a navigational purpose though. As I don't think it's good idea or practice to use sub-domains or pages in an ad-hoc way that isn't what they were originally designed for. It's just not user friendly, takes extra maintenance, and tends to cause issues further down the line. --Adamant1 (talk) 18:14, 28 August 2024 (UTC)[reply]
Yes, Atlas of the World main page (the only main page of a "system of galleries" as such that I'm aware that exists) is a gallery (in fact, any Commons wiki page without a namespace, is a gallery, and so must include media). MGeog2022 (talk) 18:23, 28 August 2024 (UTC)[reply]
How can the Main page be restructured to make useful galleries like Wikimedia Commons Atlas of the World more visible? Please make a proposal and discuss it on Talk:Main Page.: added here. MGeog2022 (talk) 18:31, 28 August 2024 (UTC)[reply]

@JopkeB: and anyone else who wants to contribute to the discussion Commons_talk:Galleries#Add_"criteria_for_creation_of_galleries"_section_to_guideline. --Adamant1 (talk) 03:11, 29 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]
    @Adamant1: I could try it if you're curious. I usually edit from my phone and I've uploaded files that way too (but I usually edit on desktop mode and on enwiki). Clovermoss (talk) 10:45, 28 August 2024 (UTC)[reply]
    @Adamant1 it works quite well as far as I can tell. The UI i even user friendlier than that of the Commons app and it adapts better to the screen size of a mobile phone than that of the Commons app (at least that's how it is when using Firefox mobile browser). However, the crux is to find the UploadWizard on mobile in the first place. You either have to find a Wikidata Infobox with an Upload media link (which is a new feature), or you have to switch to desktop view and in addition you need to edit the URL to remove the "m" for "mobile" from the URL, because even after switching to "desktop view" you'll still be on https://commons.m.wikimedia.org (mobile website) instead of the regular desktop version at https://commons.wikimedia.org. As long as you are on the mobile website, you won't see the Upload link in the menu. The other big issue with this is that you can only upload one file at a time, which is fine if you only upload 1-2 images, but I usually switch to the Commons app for batch uploads. The Commons app, unfortunately, also offers less options to edit file name, file caption, and file description than the desktop / mobile browser UploadWizard. On the app, you only have the option to enter one file "description" which will actually end up being the file name and file caption at the same time (and also the file description?). Nakonana (talk) 12:36, 28 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]
One thing I've recently noticed (and that I have not seen before): lately when you use a mobile browser (Firefox) to access Commons and when you visit a Category page that has a Wikidata Infobox, then you'll find an "upload file" link in said Wikidata Infobox. The link leads to the Upload Wizard. I was really pleasantly surprised to discover this seemingly new feature. I think it's a good approach: the link is not too big, so that it probably won't invite any misuse because you probably will only notice it if you look for it because you intend to upload something. At the same time, uploading via that link automatically adds the Category to the uploaded file from which you are accessing the link, so that there are no newly uploaded files that end up being uncategorized. One big minus in the current solution, however, is, that you can only upload only one image at a time. But maybe that also prevents misuse of the feature. I had to download the Commons app for a batch upload. Nakonana (talk) 18:17, 22 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]

tl;dr: I was on vacation with no ssh access. Webservice restarted (which could/should be done by Toolforge automatically but isn't), seems to work again. --Magnus Manske (talk) 10:25, 27 August 2024 (UTC)[reply]

Thanks Magnus. --A1Cafel (talk) 16:02, 27 August 2024 (UTC)[reply]

August 11

August 12

August 13

August 14

August 15

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]
To answer my own question: Commons:Picture of the Year/2023/Gallery. Also includes the 5%. Enhancing999 (talk) 10:05, 24 August 2024 (UTC)[reply]

August 17

August 18

August 19

August 20

August 21

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]
I have a little problem with bus bells in trams, but if it is a general term for bells in buses and trams, I have no problem.Smiley.toerist (talk) 21:37, 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]

This etching, looks like a later copy of an original work, or even a detail from one. Perhaps Bert Dewilde's book gives attribution. Failing that, you could contact the Kortrijk Museum at texture at kortrijk.be. It's highly possible that Dewilde saw this in the Rijksmuseum, but it's not been put online by them. What would be useful, is the "original title and or caption of the piece. Broichmore (talk) 12:38, 24 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]
@Enhancing999: Most things other than uploading new files can be done here without an account. A large number of edits are done by ips, some of which seem fairly regular and active editors. Do you advocate for or against something, or is this just a random comment? -- Infrogmation of New Orleans (talk) 20:00, 22 August 2024 (UTC)[reply]
In Wikipedia, (dynamic) ips generally just edit articles, each with its talk page where matter can easily be discussed. At Commons, it's hard to discuss anything with IPs as it stretches dozens of files. So IPs just end up on AN/B. Enhancing999 (talk) 20:14, 22 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]
Ah, thank you. SWinxy (talk) 23:14, 22 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]
Am I correct in understanding that no one systematically reviews the results of these "growth tasks" to see whether they have been done productively, and that it is entirely appropriate for me to revert things like this, or replace them with better choices? - Jmabel ! talk 18:29, 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]

Not familiar with the subject, so just throwing something out in hope that it's of any use: Category:Conscientious objectors, Category:Counter-recruitment, Category:Deserters. Nakonana (talk) 19:21, 22 August 2024 (UTC)[reply]
Not sure any of those fit. Category:Conscientious objectors generally have to be opposed to all wars, and its a rare status to be given to someone who is already in the military; Category:Counter-recruitment doesn't seem to fit at all; Category:Deserters fits part of the bill, so I may add it (though technically he may have been just AWOL; I'm not sure he was even charged with desertion, I'll try to work that out), but "desertion" does not carry any connotation of open resistance to a war as against just of saving one's own ass. - Jmabel ! talk 04:00, 23 August 2024 (UTC)[reply]
The German language seems to have a bit more nuance for conscientious-objection: it differentiates between de:w:Kriegsdienstverweigerung (literally: war service refusal) and de:w:Totalverweigerung literally: total refusal), where in the latter people also refuse to do any alternative service. The terminology itself also doesn't make a link to conscience as a reason for refusal (though in practice it's probably the assumed cause for service refusal). So, the terminology here might (in theory) be applied to one particular War rather than all wars in general as conscience (or general beliefs) is/are not necessarily the root for the refusal.

What might be worth considering is Category:Anti-war activists maybe? Though, his level of active resistance might not meet the threshold of activism (at least he might not have consciously chosen to be seen as an "activist" but might have just incidentally found himself in the role of a role model or something?). Furthermore, an anti-war activist might once again refer to a general opposition to all wars.

Another one that might fit the bill even better is something like Category:Resistance fighters (how is that not a category yet?). But that might be also an activity level above his. So, maybe "Resistance activist"?

There's also a Category:Vietnam War draft dodgers in Canada. Are "war dodgers", or more actively, "war evaders" / "military service evaders" a thing? Nakonana (talk) 12:36, 23 August 2024 (UTC)[reply]
U.S. conscription law recognizes two "legitimate" levels of conscientious objection, plus there is clearly a third:
  1. willing to serve in a non-combat role in the military (e.g. as a medic), recognized
  2. willing to do "alternative service" (e.g. working in a mental hospital, or firefighting in wilderness areas, etc.), recognized
  3. and clearly there is the third level, total refusal, that normally results in imprisonment for a term comparable to the draft period.
Of course, it's more complicated when someone already in the military has a change of beliefs.
He was definitely not a "resistance fighter", which implies taking up arms against the current regime.
I already have Category:Opposition to the Vietnam War, so Category:Anti-war activists would be kind of redundant.
The most common term in English for what he did is "war resister", but I don't know how well known that term is outside of activist circles. - Jmabel ! talk 18:45, 23 August 2024 (UTC)[reply]
Hmm, I see from [2] that he did claim C.O. status, so Category:Conscientious objectors does also fit. I'd really like to see something related to active resistance, though. - Jmabel ! talk 04:03, 23 August 2024 (UTC)[reply]
See also this category: Category:Partisans by country (e.g. "Italian partisans" means "Italian Resistance fighters"). Una tantum (talk) 10:28, 24 August 2024 (UTC)[reply]
@Una tantum: a completely different matter, almost a complete coincidence of the word "resistance". Resistance fighters / partisans use guerrilla tactics to violently oppose a regime, usually one they consider entirely illegitimate; war resisters use (usually) non-violent tactics—often no more than withdrawing their own active support—to try to prevent a government from carrying out a war. War resisters, especially in a democracy, don't necessarily question the basic legitimacy of the government, they just strongly oppose its policy in pursuing a war. - Jmabel ! talk 17:34, 24 August 2024 (UTC)[reply]
@Jmabel You are right. I was just pointing out the situation of categories on Commons and that this category exists, so Category:Resistance fighters (in your meaning) may confuse Italian people (perhaps others?). My 2 cents: Category:Anti-war activists is more general but less confusing. But I know that Italy is not "all the world". ;) Una tantum (talk) 17:18, 27 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]
That's perfectly fine for us B25es (talk) 16:32, 23 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: [3][4][5][6].
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]
"Taoisigh" seems a bit odd to me, I don't recall seeing that spelling (or hearing a pronunciation that matches that spelling), but as a native English-speaker, I'd consider "Taoiseach" entirely appropriate. The BBC, for example, pretty consistently use "Taoiseach". FWIW, Google gives 239,000 results for "Taoisigh", 5,820,000 for "Taoiseach", 545,000 for the phrase "prime minister of Ireland" and 419,000 for "Irish prime minister", which seems to confirm my instinct. - Jmabel ! talk 18:41, 22 August 2024 (UTC)[reply]
The plural of taoiseach is taoisigh, according to Wikipedia. --Geohakkeri (talk) 19:00, 22 August 2024 (UTC)[reply]
Interesting, I guess I'd never heard it in the plural, and certainly have no idea how to form Gaelic plurals. - Jmabel ! talk 04:06, 23 August 2024 (UTC)[reply]
So it is also OK to rename Category:Prime ministers of France to Category:Premiers ministres? And for all other countries alike? Then we might delete the Universiality principle as well. I am not a native English-speaker and I consider "Taoisigh" not appropriate because I have never heard it before, I am familiar with the name "Prime ministers" and I guess the same applies to the best part of non-native English-speakers. Why would there be an exception for Gaelic? JopkeB (talk) 04:30, 24 August 2024 (UTC)[reply]
Because in English when we talk about this person/office, we use the word "Taoiseach". Similar issue to Category:Tsars of Russia.- Jmabel ! talk 17:40, 24 August 2024 (UTC)[reply]
Is that true for other English-speaking countries as well, like the USA, Canada, Australia, New Zealand? And the word "tsar" is well known, also in other languages, and is about heads of state, not prime ministers. So I think this is not a good comparison. JopkeB (talk) 04:08, 25 August 2024 (UTC)[reply]
Definitely true for UK; for U.S. I've usually heard radio news reporters first use the word "Taoiseach", then define it once (e.g. "equivalent of a prime minister"), then use "Taoiseach". Again, I think that Google count speaks volumes: over ten times as many hits for "Taoiseach" as for "prime minister of Ireland". - Jmabel ! talk 04:51, 25 August 2024 (UTC)[reply]
"Chancellor" is also used for the German head of state. And "Teno" for the Japanese "king". Nakonana (talk) 11:48, 25 August 2024 (UTC)[reply]
So, it looks a little bit like a mess, for Germany even more than for Ireland (for Ireland there is at least a redirect, for Germany you have to figure out yourself what the category for federal prime ministers is). But luckily prime ministers of Japan‎ are still in Category:Prime ministers of Japan‎ (I could not find teno and japanese "king"). My concern are about (1) non-native English (and German) speakers AND (2) creators of templates and other technical solutions. Both groups need clear category names, with the same category name throughout the category tree. I think the Universiality principle is made for both groups. How can we apply this principle to categories for prime ministers of Ireland and the federal state of Germany (and perhaps other countries?)? JopkeB (talk) 16:27, 25 August 2024 (UTC)[reply]
I typed it wrong, of course, Tenno is a redirect. Maybe "Head of State" would work? Nakonana (talk) 17:16, 25 August 2024 (UTC)[reply]
Head of state is not the same as prime minister. Germany and Ireland both have a president as well as a prime minister of the (federal) government. JopkeB (talk) 05:02, 26 August 2024 (UTC)[reply]
Agreed that a prime minister is normally "head of government" but not "head of state". I can't think of a country with a prime ministerial system where the prime minister is considered head of state. - Jmabel ! talk 00:25, 27 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]
To be fair, your first argument only works for this special case of a country where a lot of people speak English. It doesn't work for other categories. For example, sometimes I go through the Category:Media needing categories (Cyrillic names), and there I find a decent number of files that actually are properly categorized, except that all the categories are written in Russian. The Russian community has a bot that addresses the issue to some degree but automatically searching and replacing Russian-language categories for their English counterparts, but the process is not perfect and you still find a lot of "uncategorized" Russian media. The other issue with translated categories is that there are various ways to translate one and the same thing, and it's a pain to figure out what the English name of an already existing category is. Oftentimes I go to Ru Wiki, find the subject there, follow the link to the Wikidata item from the article, and then look up the Commons category on Wikidata. There are just too many ways to "translate" even something as simple as "площадь мира" (transc.: ploshad mira, lit.: square [of] peace). You can go by Category:Peace square, Kazan or Category:Peace Square, Krasnoyarsk with a capital S, or Category:Mira Square (Kaluga)‎ (like Google does), or Category:Mir Square (the word "peace" = "mir" without the genetive suffix "-a"; Mira Square is actually equivalent to "Peace's Square", and if you want to have "Peace Square", you need to drop the genetive in Russian too "Mir Square"*), or you could translate it as Category:Square of Peace, or you use the Russian word order Category:Square Mira, which is a construction that you can find in translations of "проспект мира" (prospekt mira / Peace Avenue), such as Category:Prospekt Mira (Kaliningrad)‎ — why even bother translating when you can transcribe instead? (Now we only have to agree whether it's prospekt or prospect — k vs. c, see Category:Prospect Mira in Lipetsk‎.) Or you can just translate it like in Category:Peace Avenue, Krasnoyarsk, or you can be like Moscow and create a grammatical language monster by keeping the Russian words while using English word order: Category:Mira Prospekt in Moscow — this one raises eye brows in English speakers and Russian speakers alike.

* This is done with "площадь Ленина" (transc.: ploshad Lenina, lit.: square [of] Lenin). While the suffixed "-a" is kept in "Mir-a" for some reason, it is dropped in case of "Lenin-a": Category:Lenin Square (Ufa)‎ instead of "Lenina Square". However if it's a street (улица Ленина / ulitsa Lenina), then Lenin can keep his suffixed "-a": Category:Lenina street (Irkutsk)‎... or not Category:Lenin Street (Gdov). Nakonana (talk) 20:51, 22 August 2024 (UTC)[reply]
* typo: "It doesn't work for other countries." Nakonana (talk) 20:54, 22 August 2024 (UTC)[reply]
It is a fine balance line between translating native names into English ones or keeping them in the original language (or as a transcription for languages that have other scripts than Latin). For me names of streets and squares may be kept in the original language, except perhaps for very well known ones, like Red Square in Moscow. So the same rule as for place names (where only names known in English should be in English in Commons categories). JopkeB (talk) 09:22, 24 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 [7], 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]
I think in this case the Tagalog name is appropriate, with soft redirects from the maybe two most likely English-language names.
I'd also add: in practice, this varies a lot from country to country, and sometimes by region within a country. For example, for Catalonia, we pretty consistently favor Catalan names; for Romania, I've seen English-language names for things that it is hard to imagine anyone referring to that way, e.g. "Roman Square" for Piața Romană; it's like a Spanish-speaker calling New York's Times Square "La Plaza del Tiempo" or (even worse) "La Plaza de los Tiempos". - Jmabel ! talk 18:50, 22 August 2024 (UTC)[reply]
One example of that is how they call pizza "pie" in the New York City area. I'd prefer keeping Category:Pies for images of actual pies though. --Adamant1 (talk) 15:04, 25 August 2024 (UTC)[reply]
I think in English the name is w:Rio de Janeiro so it would not make sense to translate the name of the city. I do not know if there is an official or established name in English for this statue but Category:Statue of the Little Mermaid (Copenhagen) is in English and so is Category:Eiffel Tower. And Category:Denmark and Category:Brazil are also English. Should that be changed to local names too? I think the rule on Wikipedia is that articles is named by the most used name. So I think it would make sense to do the same on Commons. Just like it is Category:Bill Clinton and not William Jefferson Clinton. --MGA73 (talk) 07:08, 24 August 2024 (UTC)[reply]
@MGA73 the statue is "Christ the Redeemer", many know that. Unsure if using English language as the precedence will lead to the category being moved to "Category:Christ the Redeemer (Rio de Janeiro)". JWilz12345 (Talk|Contrib's.) 07:39, 24 August 2024 (UTC)[reply]
JWilz12345 I think that if there is no clear name for something then just leave the name as it is and make some redirects if needed. I would just hate to see if someone get the idea to rename hundreds of thousands of categories just to use local names in categories. --MGA73 (talk) 07:52, 24 August 2024 (UTC)[reply]
"Rio de Janeiro" also has a literal translation to English. Enhancing999 (talk) 07:55, 24 August 2024 (UTC)[reply]
@Enhancing999@MGA73 we are talking about the statue's name in English. Everyone in English-speaking world calls it "Christ the Redeemer". Little to none use "Cristo Redentor". It is understood, but I am surprised about claims here that there is no clear name of the statue in English. It is crystal clear: Christ the Redeemer. Of course, English-speaking world calls the city "Rio de Janeiro"! So: "Category:Christ the Redeemer (Rio de Janeiro)" is the most-fitting name. JWilz12345 (Talk|Contrib's.) 09:04, 24 August 2024 (UTC)[reply]
The concern is not so much this statue, but that people use the equivalent of "River of January" as it occasionally happens. Enhancing999 (talk) 09:09, 24 August 2024 (UTC)[reply]
Should that also be renamed to Category:Mga sementeryo ng militar sa Pilipinas? I think this is a strawman argument. That category name is not the official name or proper name of an actual entity unlike "Libingan ng mga Bayani" and so would run afoul of Commons:Language policy. —seav (talk) 08:47, 24 August 2024 (UTC)[reply]
The argument from MGA73 seems strange, but it's true that "Heroes' Cemetery in the Philippines" could suggest that it isn't a specific cemetery, but a class.
"in the Philippines" as a disambiguator is unusual, possibly incorrect. Enhancing999 (talk) 08:55, 24 August 2024 (UTC)[reply]
The question was "Is renaming categories with an English name to local language names a good idea?" And I think not. I think in general it is best to use English names if there is one. For example "Denmark" not "Danmark" and "Statue of the Little Mermaid (Copenhagen)" not "Statuen af Den Lille Havfrue (København)". You can always find cases where the name can be discussed and in these cases just leave the name the creator have chosen. --MGA73 (talk) 09:14, 24 August 2024 (UTC)[reply]
(1) The problem was the sample didn't quite match the question. If there is an actual name that can be referenced and that is in use, not a "river of january"-thing. (2) Your argument is about classes of objects, not specific objects. (3) there are casses where we don't use English names even for classes: Category:Betula pendula etc. Enhancing999 (talk) 09:23, 24 August 2024 (UTC)[reply]

Marking with NowCommons

I would like to do a little test so I'm looking for a smaller wiki where someone would like to know if there are files with a duplicate on Commons. It would be best if there is known to be at least 1 file that is on Commons so I know that it works. --MGA73 (talk) 17:11, 22 August 2024 (UTC)[reply]

Try on lmo.wiki! Sciking (talk) 10:36, 24 August 2024 (UTC)[reply]
Thank you Sciking. It is a perfect wiki to test on. Sadly the test did not go as well as I planned. I made this list lmo:Utent:MGA73/Sandbox but it involves a few manual steps. But perhaps it is faster just to do the manual step than to spend lots of time to try to get around :-D --MGA73 (talk) 13:25, 24 August 2024 (UTC)[reply]
It's an interesting idea even with the manual steps being involved. If you don't mind me asking, what's the ultimate goal here though? Not to say there has to be one, but I'm kind of interested in how the tool can be used as part of someone's workflow or whatever once you get the kinks ironed out. --Adamant1 (talk) 13:54, 24 August 2024 (UTC)[reply]
The goal is just to make it easy to make a list of files that is also on Commons. Sometimes the local file can just be deleted. Sometimes the local file is the source and the file on Commons needs to be fixed to attribute the original author. And sometimes the local file shows that the file on Commons is actually a copyvio. --MGA73 (talk) 14:15, 24 August 2024 (UTC)[reply]

If anyone would like to test a bigger wiki thats okay too now. But I prefer wikis with less than ~50k files. --MGA73 (talk) 13:25, 25 August 2024 (UTC)[reply]

Category:Videos by subject

It might just be me but "Videos of subject" seems more fitting for the vast majority of subcategories considering most of the categories are about abstract and intangible concepts--Trade (talk) 21:17, 22 August 2024 (UTC)[reply]

"Videos by subject" is basically shorthand for "Video categories, sorted by subject", analogous to "Houses by country" or "Music by year". - Jmabel ! talk 04:12, 23 August 2024 (UTC)[reply]
I was talking about the subcategories specifically. Trade (talk) 18:12, 23 August 2024 (UTC)[reply]
"Videos of culture" or "Videos of political correctness" would be rather odd. - Jmabel ! talk 18:47, 23 August 2024 (UTC)[reply]
I was just going to say that. "Videos of culture" doesn't make any sense. It probably depends on the subject of the categories though. Like "videos of cats" would be perfectly fine. --Adamant1 (talk) 13:07, 24 August 2024 (UTC)[reply]
This seems like just guessing what Trade means here, couldn't you make it clearer? Is this thread about that several subcats like "Videos about culture‎" should be moved to "Videos of culture‎" or that they should be moved to "Videos of subject culture" or that subcategories of subcategories should be in that cat directly or something else? "the vast majority of subcategories" is already called "Videos of XYZ" so this post is quite unintelligible. Prototyperspective (talk) 10:11, 26 August 2024 (UTC)[reply]
I meant to say videos about, not of Trade (talk) 12:43, 26 August 2024 (UTC)[reply]
If you're arguing there should be more cats called "Videos about XYZ" I agree and noticed this issue as well. Many videos in "Videos of XYZ" cats do not actually depict XYZ or only animations thereof. I think "Videos of XYZ" cats should be split with some files being moved to a parent cat "Videos about XYZ". If you're pro renaming/moving the cats I'd disagree for most cases – the standardized "Videos of" naming is useful for finding things and when it comes to cases where the videos actually show XYZ. There are many "Videos of" cats that contain files that better fit into "Videos about…" and in some cases the two cats exist in parallel like with Category:Videos of music and Category:Videos about music. Prototyperspective (talk) 14:09, 26 August 2024 (UTC)[reply]

How would you feel about Category:Videos by subject depicted? Would that be a good parent category?--Trade (talk) 13:30, 27 August 2024 (UTC)[reply]

I'm again a bit unsure what exactly you're asking about. That wouldn't change how the subcategories are named. One could move the current category to this title but it wouldn't change much and is more clumsy than the current one which I think is better. Maybe you're asking what a parent category to videos of and other categories would be called but the current one linked in the thread title works for that just fine. Prototyperspective (talk) 16:52, 27 August 2024 (UTC)[reply]

Sign up for the language community meeting on August 30th, 15:00 UTC

Hi all,

The next language community meeting is scheduled in a few weeks—on August 30th at 15:00 UTC. If you're interested in joining, you can sign up on this wiki page.

This participant-driven meeting will focus on sharing language-specific updates related to various projects, discussing technical issues related to language wikis, and working together to find possible solutions. For example, in the last meeting, topics included the Language Converter, the state of language research, updates on the Incubator conversations, and technical challenges around external links not working with special characters on Bengali sites.

Do you have any ideas for topics to share technical updates or discuss challenges? Please add agenda items to the document here and reach out to ssethi(__AT__)wikimedia.org. We look forward to your participation!

MediaWiki message delivery (talk) 23:18, 22 August 2024 (UTC)[reply]

August 23

Uncategorized categories again

As of 11:11, 22 August 2024 we have a new report at Special:UncategorizedCategories (for the first time in 6 weeks). Again there are about 1500 categories here. I'll do my best to delete the ones that have neither parents nor content (files, subcats); most other work needed here is not admin work, just basic categorization work, and any competent help would be welcome. If someone reads Chinese or Japanese, there are a fair number of at the end of the list. Also, throughout the list, quite a number of categories for people from Hungary, which would be easiest for someone who can read Hungarian. But there is plenty there for those who know English or any of the Western European languages. - Jmabel ! talk 04:20, 23 August 2024 (UTC)[reply]

 Delete YES please delete nonsense. Taylor 49 (talk) 05:38, 23 August 2024 (UTC)[reply]
The list does not seem to be very accurate or up to date (eg. Category:April 2023 Kaliningrad Oblast photographs, or Category:Anni-Albers-Straße) --D-Kuru (talk) 06:07, 23 August 2024 (UTC)[reply]
I'm unsure what the deal is with the former, but the latter didn't have categories at the time the list was updated. Those were added about an hour later. ReneeWrites (talk) 07:37, 23 August 2024 (UTC)[reply]
Category:April 2023 Kaliningrad Oblast photographs Seems to be because the category was added via a template, and i guess there never was a linksupdate (If you went to any of the categories the page was allegedly in, you would have found that it was present in them [until just now when i null edited it]. In any case, cases like that can usually be fixed with a null edit. Bawolff (talk) 09:23, 23 August 2024 (UTC)[reply]
There are always a few false positives, usually because of template-added categories where something didn't propagate correctly, but not enough to make the task significantly more difficult. - Jmabel ! talk 18:49, 23 August 2024 (UTC)[reply]

I believe Túrelio and I have now deleted all of the several hundred parentless, memberless categories except for a few that look likely to be useful soon, where I've asked their respective creators to either use the category or request deletion. There are also, as remarked above, a dozen or two false positives.

So: the remaining work here is mostly the usual categorization work, on somewhere around 1000 to 1200 categories, and help from anyone who is decent at categorization would be greatly appreciated. - Jmabel ! talk 19:01, 24 August 2024 (UTC)[reply]

Could we have the list regenerated, now people have been working on it for a couple of days? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:27, 24 August 2024 (UTC)[reply]
Commons:Report Special:UncategorizedCategories. Maybe the update can be automatized (bot request) Enhancing999 (talk) 22:42, 24 August 2024 (UTC)[reply]
@Pigsonthewing: very unlikely. Last time they left us hanging six weeks between reports, even after I repeatedly asked once it had passed the 1 month that is supposedly how often they run it. They used to run it every three days, but apparently it involves some monster JOIN that they consider to heavily burden the servers. - Jmabel ! talk 04:55, 25 August 2024 (UTC)[reply]
That's a pity. I fixed a few, when you first posted, but now it's hard to find any that still need doing, so I'm disincentivised to continue. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:41, 25 August 2024 (UTC)[reply]
@Pigsonthewing: Start from somewhere other than the start of the alphabet, there should be plenty. Especially people by name. - Jmabel ! talk 18:38, 25 August 2024 (UTC)[reply]

{{Large image}}

What file size on commons is now regarded as being very ‘’high-resolution’’, and should, therefore, be marked with {{Large image}}? Does this vary by file type. Broichmore (talk) 13:08, 23 August 2024 (UTC)[reply]

This is a good question... Some years ago, files with 50 megapixels were considered large. Today, I would see large images as images with higher resolutions than the common ones (70 megapixels and more), of course with respective level of details. AFAIK "large" refers to the amount of pixels, not to the file sizes in MB, GB or whatever --PantheraLeo1359531 😺 (talk) 17:42, 23 August 2024 (UTC)[reply]
Would that advice apply, anywhere in the world? This is the image that raised the question. It's less than 21 megapixels. I find it, just a tad slow if you fully open it up, where I am (UK). However it presents no problems on wikipedia, or the front end of commons. Broichmore (talk) 10:30, 24 August 2024 (UTC)[reply]
I would say, yes. When we compare this 21 MP image to the largest 5 or 1 %, then this image is of course not large (I would not consider it as large), and the largest 5 % are. As it is a JPEG, the filesize is also not large. If it is a TIFF with 32 bits per channel, then it may qualify as large image. Of course, having a low internet connection, it may take long to load, but the larger ones take longer of course. --PantheraLeo1359531 😺 (talk) 16:16, 24 August 2024 (UTC)[reply]
I'd put the line on photographs at over 50 MP or over 65 MP. Modern phones, even cheap ones, frequently have 50 MP cameras, and 100 or 200 MP sensors in smartphones seem to work best when taking 50 MP or smaller pictures.. Even professional cameras top out at 60 MP, with the exception of $4K Fujifilm cameras or $35K Hassleblads. So that's the line between normal photo and multi-shot merges or extremely high end equipment, IMO.--Prosfilaes (talk) 21:19, 25 August 2024 (UTC)[reply]
Isn't this about browsers freezing not actually image size? I dont think it should matter what the average image size is, only what does or does not freeze a browser. I guess someone should test various sizes and see. Bawolff (talk) 17:15, 28 August 2024 (UTC)[reply]

Promotional material in image description?

File:BikersForTrump1.RollingThunder.WDC.29May2016 (27672036472).jpg includes promotional links to the organization's facebook page with a request to follow the page. Also links to other websites. Is this allowed? RoySmith (talk) 14:54, 23 August 2024 (UTC)[reply]

As far as I know, it is okay --PantheraLeo1359531 😺 (talk) 17:43, 23 August 2024 (UTC) Seems like it isn't --PantheraLeo1359531 😺 (talk) 16:17, 24 August 2024 (UTC)[reply]
Not OK, regardless of the subject, removed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:46, 24 August 2024 (UTC)[reply]
Should be removed, and has been removed. That text was imported from the Flickr description, and neither its formatting nor its content were appropriate for Commons. Omphalographer (talk) 16:15, 24 August 2024 (UTC)[reply]

Crop Tool, again

Is anyone else having trouble with it today? --Rosiestep (talk) 17:16, 23 August 2024 (UTC)[reply]

Yeah, seems to be down for me :( ReneeWrites (talk) 18:05, 23 August 2024 (UTC)[reply]
Is there an estimate as to when Crop Tool will be functioning again? --Rosiestep (talk) 01:25, 25 August 2024 (UTC)[reply]
@Rosiestep: Given that the problem is that the person who was responsible for it abandoned it, and no one has properly taken it over, I don't think anyone could make a meaningful estimate unless they were inclined to take responsibility for it themself. - Jmabel ! talk 04:57, 25 August 2024 (UTC)[reply]
@Rosiestep: Crop Tool is working again. ReneeWrites (talk) 07:18, 26 August 2024 (UTC)[reply]
For me is does not. I tried it with this file. Wouter (talk) 07:59, 26 August 2024 (UTC)[reply]
Thank you for the notification, ReneeWrites. It's working for me, too, now. --Rosiestep (talk) 14:23, 26 August 2024 (UTC)[reply]
For me, it still doesn't work. Wouter (talk) 14:42, 26 August 2024 (UTC)[reply]
Crop tools is working again. Wouter (talk) 18:58, 28 August 2024 (UTC)[reply]

August 24

Fix for mobile description table

Headers are too thin on mobile [1]

Please update: MediaWiki:Filepage.css with a specificity fix like this: diff fix Module Information styles.css. Nux (talk··dyskusja) 08:06, 24 August 2024 (UTC)[reply]

Pinging some people that did some updates in the past; sorry if you're busy 😊 @Ebrahim, @Lucas Werkmeister. Nux (talk··dyskusja) 08:09, 24 August 2024 (UTC)[reply]
Just synced it with your version, thanks −Ebrahimtalk 09:51, 24 August 2024 (UTC)[reply]
@Nux: Please use {{Edit request}} next time, it’s usually faster than pinging a subset of admins :) Lucas Werkmeister (talk) 11:49, 24 August 2024 (UTC)[reply]

Rename ship

I researched the ship and I could not find the ship under the AKKO name. The ship is registered as IMO 9217230, and known as Nils Holgersson, also a TT-line ship. Should I create a duplicate AKKA (ship, 2001) category? AKKA ship. Smiley.toerist (talk) 12:49, 24 August 2024 (UTC)[reply]

It is unclear when the name change took place: sv:M/S_Akka.Smiley.toerist (talk) 12:56, 24 August 2024 (UTC)[reply]
From de:Akka (Schiff, 2001): Spring 2022. (Jan 20nd, or before, see [8]) --Raugeier (talk) 07:02, 25 August 2024 (UTC)[reply]
Yes, I would name the cat AKKA (ship, 2001), on the basis that an Engish Wikipedia article would almost certainy use Akka, in a title. Broichmore (talk) 16:19, 25 August 2024 (UTC)[reply]

I created a new Category:AKKA (ship, 2001). There is a problem in Wikidata as the template ask for a new data-item. A name change should never be a reason to create a new data-item.Smiley.toerist (talk) 09:17, 27 August 2024 (UTC)[reply]

I've fixed the wikidata entry. Broichmore (talk) 11:42, 27 August 2024 (UTC)[reply]
"A name change should never be a reason to create a new data-item." @Smiley.toerist: are you saying category for ship name (P7782) should not exist? It was introduced on Wikidata 28 May 2020 and as far as I know has up to now been uncontroversial. You can see wikidata:Property talk:P7782 for the rationale and documentation. - Jmabel ! talk 19:21, 27 August 2024 (UTC)[reply]

August 25

Category subtree Category:Floor plans of churches by country

The country-specific subcategories of Category:Floor plans of churches by country are partly named after the scheme Plans of churches in...., partly after Floor plans of churches.... This is annoying, especially using a tool like HotCat which lists Subcategories alphabetical. Additionally, there's a danger of creating unneccessary categories (see Plans of churches in Spain vs. the newly created Floor plans of churches in Spain). Is it ok to standardize the subcategories to "Floor plans of..."? Fl.schmitt (talk) 09:46, 25 August 2024 (UTC)[reply]

It seems to be the opposite with your example of Spain for some weird reason but wouldn't "floor plans" inherently be a sub-category of "plans"? I guess I'm not seeing what needs to be standardized here beyond that though. Its not like they are mutually exclusive. You can have both a plan and a floor plan for some things. It's not really that clear what makes something the former versus the later in a lot of cases either. If anything I'd say "floor plans" is probably pointless, but there no reason not to both as long as the "floor plans" is a child of "plans", instead of the other way around. --Adamant1 (talk) 12:30, 25 August 2024 (UTC)[reply]
@Adamant1: Since English isn't my native language, I'm not sure regarding the details. But according to https://dictionary.cambridge.org/dictionary/english/plan, a plan is "a drawing of a building, town, area, vehicle, machine, etc. that only shows its shape from above, its size, and the position of important details", while a floor plan is "a drawing that shows the shape, size, and arrangement of rooms in a building as viewed from above" (https://dictionary.cambridge.org/dictionary/english/floor-plan?q=Floor+plan; my emphasis; see also Plan view (redirect) and Floor plan, while Architectural plan redirects to Floor plan). Since almost all image files even in the "Plans of churches..." categories are in fact floor plans, the naming of those categories is IMO misleading. If there are really "plans" and not "floor plans", they would belong to Category:Architectural drawings of churches or a to-be-created category Category:Plans of churches - ooops, it exists already, but seems to contain mostly floor plans (also its subcategories). I think there's some more work to do for a consistent category structure here. Fl.schmitt (talk) 15:37, 25 August 2024 (UTC)[reply]
Admittedly I didn't look through every single category or image related to this but there are "plans" for churches and other buildings that include the courtyards, parking lots, and other elements that aren't specifically part of the buildings floor. If you want some examples check out this link. I guess you could maybe call them "architectural drawings" but it's not just about the architecture in those cases and most (if not) architectural drawings are more technical anyway. Usually they include exact measurements, angles, and similar elements. whereas floor plans tend to be pretty basic. So I'd say more general plans should go in categories for plans. Floor plans that don't other elements should be in categories specifically for floor plans, and more complicated building plans that involve measurements, angles and the like should go in something akin to a category for architectural plans. --Adamant1 (talk) 15:45, 25 August 2024 (UTC)[reply]
@Adamant1 - sounds good, I agree: we distinguish between plans, floor plans and architectural plans. But now we have reached the starting point again: the category subtree of Category:Floor plans of churches by country contains categories named "Plans..." where floor plans are collected (other types of plans are available only in very rare cases - almost all "plans" in that subtree are floor plans). If we distinguish, the category names should reflect the distinction - so: is it OK to standardize the naming of the subcategories to "Floor plans of..."? Fl.schmitt (talk) 16:35, 25 August 2024 (UTC)[reply]
FWIW, I worked in architectural CAD for some years, and anything horizontal is likely to be called a "plan". "View from above" in this context does not mean only what could be seen from the air: a "floor plan" is, indeed, the floor as it would be seen from above if the rest of the building weren't in the way. Another common drawing type besides those mentioned above is an "inverted ceiling plan" ("inverted" because of course you never see the ceiling from above, so it is inverted from how you could ever see it). - Jmabel ! talk 18:45, 25 August 2024 (UTC)[reply]

Can I upload bt2020nc/bt2020/smpte2084(PQ) HDR AVIF images to commons and use them in wikipedia articles?

Sometimes in articles concerning HDR technologies there is a need to present a truly HDR image.

I want to create a (public domain) rendition of ITU-R Rec. BT.2111 (an HDR&WCG color bars test signal image) to be used in article SMPTE_color_bars. It has to be presented with full PQ HDR and BT.2020 WCG to be able to illustrate properly. The VUI information would be bt2020nc/bt2020/smpte2084 (in ffmpeg style).

I am considering AVIF since it seems to have better support and overall easier to understand if you know ffmpeg well.

But considering that not all devices support HDR and/or WCG, do I need to also create a SDR version? maybe also a SDR & sRGB version?

For what it's worth, this test signal can be seen in some recent large scale high end television broadcasts (& the studios they are produced in) like the Paris Olympics. Hym3242 (talk) 14:23, 25 August 2024 (UTC)[reply]

AVIF is unfortunately a not accepted format on Commons. But if you want an HDR image uploaded, you can upload it as TIFF file with 32 bits per channel, and also upload a tonemapped JPEG with it. You can add a note at "other versions" on the file page to make a hint that there is another version of your file like here File:Kugelpanorama des Botanischen Gartens in Hof (Saale) 20240713.tif. Kind regards --PantheraLeo1359531 😺 (talk) 17:14, 25 August 2024 (UTC)[reply]
Thank you for your response. I guess I would use a BT.2020 or at least P3D65 SDR image. Or seek other HDR image formats... I have some additional questions though. Do TIFF HDR images need that high bit depth to avoid quantization artifacts because it does not support the Perceptual Quantizer transfer characteristics? Is the new ISO HDR (JPG with gain map) accepted on Commons? Hym3242 (talk) 17:23, 25 August 2024 (UTC)[reply]
I am afraid that I cannot answer your first question. If the ISO HDR attribute can be saved in a *.JPG file, it should be possible, but it sounds like an addition in a later format like JPEG 2000 oder JPEG XL to me --PantheraLeo1359531 😺 (talk) 06:07, 27 August 2024 (UTC)[reply]

Signature on Japanese woodblock

The signature, probably rotated 90 degrees.
The signature, probably rotated 90 degrees.

I was hoping someone might be able to help identify the signature from the block print in the upper right quarter of File:Helix, v.4, no.5, Aug. 29, 1968 - DPLA - 841a1a68f4295fee3a912baf0c87caaa (page 8).jpg. Presumably Japanese, presumably a woodblock, probably 20th-century, probably rotated 90 degrees; page is PD in the U.S. because it was published in the U.S. in 1968 without copyright notice. - Jmabel ! talk 20:10, 25 August 2024 (UTC)[reply]

I can’t identify it, but it looks more like chinese than japanese to me. Hym3242 (talk) 21:12, 25 August 2024 (UTC)[reply]
I can't rule that out, but the style of the block print as a whole looked more Japanese. - Jmabel ! talk 00:09, 26 August 2024 (UTC)[reply]
@Fish bowl: is a knowledgeable Wiktionarian who knows CJK languages and may be of assistance. —Justin (koavf)❤T☮C☺M☯ 11:08, 26 August 2024 (UTC)[reply]
For anyone interested, I uploaded a rotated and cropped version of the logo here and ran it through the WikimediaOCR tool using Google Cloud Vision OCR. Although it doesn't seem to have Chinese or I just missed it. But in Japanese it seems to translate to WWW. There was something about someone reaching up to the clouds for a ride when I did it once to, but I'd take both with a grain of salt. Regardless, probably it's either Japanese or some other Asian language. It doesn't really look like Chinese. It could be though. Maybe someone else can find another OCR tool to try it with or get better results using the WikimediaOCR tool then I did. --Adamant1 (talk) 13:03, 26 August 2024 (UTC)[reply]
  • It seems like the character “雅” to me. Probably a part of the first name of the creator of this artwork. Masashi (“雅”), Masaya (“雅也”), Masayuki (“雅行”), Masami (“雅美”), etc. --トトト (talk) 16:46, 26 August 2024 (UTC)[reply]
I am not an expert in w:Seal script, but I agree with the evaluation by トトト that it is 雅. For comparison, here is a Japanese seal script dataset: the left-hand-component seems to be typically shaped differently; the shape in may be influence from the regular script form of 牙. Fish bowl (talk) 21:08, 26 August 2024 (UTC)[reply]
Not to say it isn't seal script, but there's some logos of Japanese Woodblock publishers here that look like they have a similar style. Although it's possible Chinese woodblock artists worked in Japan or visa versa and it's still seal script. --Adamant1 (talk) 03:16, 27 August 2024 (UTC)[reply]

August 26

Debugging screenshots

Hello! Some time ago I've uploaded a bunch of screenshots that served to debug a Wikipedia script. I was wondering what is the stance Wikimedia Commons has for such cases? They have served their purpose now and I was thinking to mark them all for deletion (even though this would create some "holes" in the discussions they were used). — Klein Muçi (talk) 09:27, 26 August 2024 (UTC)[reply]

Deleting the screenshots can make past issues and code changes less understandable so if they're used they probably should or need to be kept even if the likelihood of being useful is usually low. I don't see why screenshots of other bugs should be deleted either. They just should all be in some screenshots of bugs category for example (currently at least Category:Wikipedia screenshots which does have a subcat for bugs) so that they can be easily excluded or shown only at the bottom of WMC search engine search results (this is what could be constructive, not deletions). Prototyperspective (talk) 10:17, 26 August 2024 (UTC)[reply]
Why would they be deleted? —Justin (koavf)❤T☮C☺M☯ 11:07, 26 August 2024 (UTC)[reply]
Because it is that user who uploaded these images and They have served their purpose now. Not a constructive question. Prototyperspective (talk) 12:17, 26 August 2024 (UTC)[reply]
I don't know why you're talking to me that way and I was asking someone else. Could you please not? —Justin (koavf)❤T☮C☺M☯ 12:22, 26 August 2024 (UTC)[reply]
I answered your question then I noted that I don't find it a constructive question since the user did very well to specify exactly what you asked about. Sorry if it sounded not nice to you that wasn't intentional. Prototyperspective (talk) 12:28, 26 August 2024 (UTC)[reply]
You answered a question that was asked to a different person, so that seemed rude to me. Thanks for your apology and giving your perspective. —Justin (koavf)❤T☮C☺M☯ 12:37, 26 August 2024 (UTC)[reply]
@Prototyperspective, Koavf, thank you both for your answers! To provide some context for the discussion, these are the some of the screenshots that I was referring to:

As you will see, they may appear to be very "buggy" (by "nature") and pretty random as they've only served as, what I can call, "temporary" illustrations between me and the script developer which requested them to understand better what problem I was describing to them. It is my belief that we actually should have a way to upload temporary images for such cases which get autodeleted and a way to handle the deletions in the discussions that use them in a more graceful manner. They provide no value other than serving their temporary purpose of showing what am I seeing at that moment in my screen to another interested person for on-wiki work reasons. Until we have such a tool, I think we can just do the process manually, uploading and deleting them later when they have served their purpose. — Klein Muçi (talk) 08:56, 27 August 2024 (UTC)[reply]
That makes sense, but note also that having pictures of bugs that have been fixed can be very useful for future debugging as well or simply illustrative of what "bugs" are (e.g.) at Wikiversity. There is still a plausible purpose for these to exist and while we could in principle have too many such screenshots and the marginal utility of each one decreases, I think there's value in keeping them for these potential uses as well as referring to them in existing historical discussions. —Justin (koavf)❤T☮C☺M☯ 11:21, 27 August 2024 (UTC)[reply]
Go ahead and tag these for deletion ({{SDG7}}). No need to overthink it. You uploaded these files as part of a technical discussion, not as educational materials; we don't need to imagine educational uses for these images after the fact.
Re. temporary images - I think there's a larger use case for a process on Commons for tagging images which should be deleted if a "parent" page is deleted - e.g. decorative images, charts and diagrams, photos of questionably notable topics, etc. Basically, some lightweight way of marking images which should be considered for deletion once they're no longer in use. Omphalographer (talk) 23:15, 27 August 2024 (UTC)[reply]
I think the user is (at least also) asking about the general issue at scale, see stance Wikimedia Commons has for such cases. The cases uploaded by the user were examples of Debugging screenshots. Screenshots of bugs would usually remain in use or not be in use on a Wikimedia project in the first place (also is linking to a file but not embedding it a file-use?) so I don't think temporary files would solve that even if they would used often which I doubt. I guess currently the best way to deal with this issue is to either not categorize the screenshots or categorize them into cats like "Screenshots of Wikipedia problems and bugs" which may first need to be created which then could e.g. be easily excluded from searches via deepcategory search operator or downranked in the search results and less well indexed in Web search engines (which however still don't seem to index most media on WMC anyway). Prototyperspective (talk) 23:34, 27 August 2024 (UTC)[reply]
I believe I'll tag them for deletion and let the involved parties in the deletion discussions decide for further action.
As for the "temporary uploads" system, I really think that's something that we need. Many technical discussions will at some point require screenshots of what the other user is seeing. This is especially useful in help desks with new users which lack the ability to best describe what their issue is. Having the ability to quickly showcase your screen view if needed can be greatly beneficial in such scenarios. This could also be handled locally on projects but not all of them have that enabled (my homewiki - sqwiki - doesn't, for example). I'm thinking for something as simple as a tick box with "Autodelete after XX time". (And possibly a way to gracefully handle these discussions later on.) - Klein Muçi (talk) 08:18, 28 August 2024 (UTC)[reply]

JPEGs versus PDFs for multipage scans

I have a couple of books and magazines I'd like to scan and upload at some point. I can't decide if I want to upload them as PDFs or JPEGs though. I suppose I could always upload both. Just uploading PDFs would probably be easier though. But I'm wondering what the pros and cons of both formats are and/or if there's a preference on here. Clearly people upload more JPEGs then anything else but its hard to conclude anything from it except that photographs are more popular then books on here. Adamant1 (talk) 18:50, 26 August 2024 (UTC)[reply]

One .pdf to have the complete work in one place in a convenient, readable format, and illustrations exported individually so they can be used on Wikisource or wherever else. I also personally like linking back to a .pdf hosted here on Commons for those extracted/exported images, as opposed to linking to a file hosted externally. Wikisource also uses .pdf (and .djvu) files as source files when transcribing books. This is personal preference though, not necessarily what other people prefer doing. ReneeWrites (talk) 19:10, 26 August 2024 (UTC)[reply]
Upload them to the Internet Archive as TIFFs or PNGs (as a ZIP file named whatever_images.zip with the files numbered in the order they should appear), and then upload a PDF to here. Internet Archive will autogenerate many formats, and is better at handling full-size original scans than we are. Any images should be uploaded here as PNGs or JPEGs, appropriately cropped, but that can be done from the original scans by anyone if you uploaded them to the Internet Archive; there's also no reason to ever upload full-page scans instead crops to the image if you've already uploaded a PDF.--Prosfilaes (talk) 21:21, 26 August 2024 (UTC)[reply]
One reason to upload per page could be file size. If the scans have a high resolution and if there are many pages uncompressed PDF files could hit the file size limit. GPSLeo (talk) 05:49, 27 August 2024 (UTC)[reply]
I agree that uploading to IA is often the easiest way to go for books. You can create a zip file that's named like foo_images.zip and it'll turn that into a PDF and give it a nice browsing interface, then you can use toolforge:ia-upload to transfer the book to Commons. The main reason I'd upload individual files to Commons is if lots of them could do with being cropped to extract illustrations — if they're on IA that'll be a bit of a long-winded process. Sam Wilson 11:34, 27 August 2024 (UTC)[reply]

August 27

I nominated Carl Johan Adlercreutz for deletion because this gallery page has only one image, which in my opinion is not enough to meet the criterium "to present readers with a structured and meaningful collection of the media found here on Wikimedia Commons" (see Commons:Galleries). But it turned out that deleting this page would break the interwiki links to Commons. So the administrator on duty did not want to delete it and asked me to discuss this issue here (see User talk:AFBorchert#About Commons:Deletion requests/Carl Johan Adlercreutz).
My solution is simple: just change the interwiki links to Commons in the Wikidata item (in this case: w:Q958784), to the Commons category and the problem is solved.
 Question Is this indeed a good solution? Do you have a better solution? And do you know other cases like this? JopkeB (talk) 05:30, 27 August 2024 (UTC)[reply]

I never got why galleries would be used as interwiki links instead of categories or what the benefit to doing it that way is. So I don't see why just changing interwiki links wouldn't be an option here. Although I'm interested to know what AFBorchert's opinion is about it. --Adamant1 (talk) 05:49, 27 August 2024 (UTC)[reply]
@Adamant1 blame the bot (e.g. Pi bot (talk · contribs) that seems to put the gallery pages as superior to the categories. See this. This eventually forced me to create resident gallery article of the town in the disputed waters (Kalayaan, Palawan). JWilz12345 (Talk|Contrib's.) 06:19, 27 August 2024 (UTC)[reply]
@JWilz12345: See d:User:Mike Peel/Commons linking, category links go on category items where they exist, so the system works. It's not 'superior' at all. All tools should auto-follow topic's main category (P910)/category's main topic (P301) as needed to find the commons link. Thanks. Mike Peel (talk) 18:38, 27 August 2024 (UTC)[reply]
There are at least two target groups:
  • We, as Commons editors, may indeed prefer a link to the category, as I do.
  • End users, looking for images for a Wikipedia page or for their own presentations and papers, it might be better to have a link to the gallery page, where they can more easily find good images (when it is a good gallery).
You can still join the discussion about this subject on Wikidata:Requests for comment/Proposal to create a separate section for "Commonswiki" links. JopkeB (talk) 09:27, 27 August 2024 (UTC)[reply]
@JopkeB: I forget what it is right now, but isn't there already a property for linking to galleries on Wikidata's end? What's wrong with that assuming there is one? --Adamant1 (talk) 15:21, 27 August 2024 (UTC)[reply]
@Adamant1: What exactly do you mean with "Wikidata's end"? In Wikidata you can add a link to a Commons gallery with d:P373 and at the bottom. The one at the bottom is the real one, the other one is just information (as far as I figured out). Each Wikidata item can only have one link at the bottom to Commons: either a gallery page or a category. Is this an answer to your question? JopkeB (talk) 03:12, 28 August 2024 (UTC)[reply]
@JopkeB: You can get to Commons through either one. So I don't think there is a "real one" per se. It's just different ways of showing the same information. I use links attached to properties to get to things on Commons all the time myself. --Adamant1 (talk) 03:24, 28 August 2024 (UTC)[reply]
I always use the property and not the site link when using Wikidata for a tool for exactly that reason that I do not know if the site link is what I need. GPSLeo (talk) 05:48, 28 August 2024 (UTC)[reply]
Correct link here: Wikidata:Wikidata:Requests for comment/Proposal to create a separate section for "Commonswiki" links. Dogfennydd (talk) 10:14, 27 August 2024 (UTC)[reply]
I wanted to have some community input before we are going to replace single-image galleries that serve as target of interwiki links in greater numbers by their respective categories. This would require not just changes here at Commons but also at Wikidata. Personally, I prefer to have categories as the main target of interwiki links. But my personal preference cannot be the guideline for administrative decisions. --AFBorchert (talk) 06:17, 27 August 2024 (UTC)[reply]
For single-image gallery pages I don't see how that would ever be an issue, especially if they don't even link to any other pages or categories on Commons. As a result, rather than providing a curated overview of a topic, they just hide information instead. ReneeWrites (talk) 10:58, 27 August 2024 (UTC)[reply]
It seems that 1-image-galleries are not valid content and are speedy deleted. Nothing is lost as the category has an infobox too.
For ill-kept galleries, I think the usual practice is to redirect them to categories.
A more general solution would be to link categories directly. Categories then can include one or several galleries providing selections thereof.  → Enhancing999 (talk) 11:13, 27 August 2024 (UTC)[reply]
Yes, it is a good solution and I think it should be done more often e.g. by people scanning for gallery pages set on Wikidata items. Usually having the category page there is much more useful and appropriate and gallery pages often have only very few images or are outdated. I think the concept of galleries isn't working well on WMC and shouldn't drown out category pages in the Search when clicking on "Categories and Pages" (that is a separate issue however).
A better solution would be to not allow gallery pages to be set on Wikidata items. The problem with that is that there still are often no good ways to browse categories in ways that highlight/sort high-quality and/or likely-highly-relevant files somehow, with one way for that proposed here (two code issues that prevent a similar solution to work using Help:FastCCI or Deepcat gadget are phab:T369808 and phab:T367652). Gallery pages can do that and for example pick good-quality examples of major concepts relating to the category/subject which could be useful in large categories with many files/subcats. Even when considering that, many people don't (wouldn't) know that there's more files relating to the subject and think the files included in the gallery is all there is so interlinking Wikipedia/Wikidata with gallery pages is more a problem than anything else and the aforementioned issue relates more to how they would be best replaced. Prototyperspective (talk) 11:40, 27 August 2024 (UTC)[reply]
A category and a gallery are two different things in two different namespaces and they should be linked to two different Wikidata items, e.g. R.E.M. and w:en:R.E.M. at d:Q134969 and Category:R.E.M. and w:en:Category:R.E.M. at d:Q8616721. —Justin (koavf)❤T☮C☺M☯ 11:55, 27 August 2024 (UTC)[reply]
The user reading a Wikipedia article would in most cases find a linked WMC category page more useful as is usually the case. They shouldn't be buried linked only on Wikipedia categories which nearly nobody looks at and your comment essentially ignores all the points / issues raised in this thread without providing any reasoning (except noting that these are different namespaces which probably all users in this thread already know). Prototyperspective (talk) 12:19, 27 August 2024 (UTC)[reply]
The weird thing even about reasonable galleries like commons.m.wikimedia.org/wiki/R.E.M. is that they don't even link to categories (follow the mobile link I provided to check).
 ∞∞ Enhancing999 (talk) 12:23, 27 August 2024 (UTC)[reply]
(they display categories at the bottom).
 ∞∞ Enhancing999 (talk) 12:38, 27 August 2024 (UTC)[reply]
You probably meant to say they don't display categories at the bottom (or at the top if you configured that in the prefs which I think is useful). That is not specific to galleries but also affects file pages and category pages on WMC. Related change requests include this, this, and this and there is no good reason to hide them on mobile (aka the way by now probably most readers access the site). Prototyperspective (talk) 12:57, 27 August 2024 (UTC)[reply]
Actually, they don't display at all to users who aren't logged in. So even well kept galleries are a dead-end.
 ∞∞ Enhancing999 (talk) 13:06, 27 August 2024 (UTC)[reply]
Again, you come to me with some needlessly provocative and rude language. What is your solution to the problem of the fact that there are two separate Wikidata items and how four pieces of content across just these two wikis (never mind other sister projects or languages) would be handled? I've had this exact same conversation multiple times and many users in fact did not understand the semantic differences between different namespaces or how Wikidata works. Since you evidently do, I'mm very interested in knowing your trenchant solution. —Justin (koavf)❤T☮C☺M☯ 14:54, 27 August 2024 (UTC)[reply]
I tend to agree with Prototyperspective that it isn't clear what solution you are suggesting to the 1-image-dead-end-gallery for mobile users Jopke tries to fix.
That galleries are somewhat different, I think everybody knows. Your sample shows that even well kept galleries are more of a dead-end to mobile users than I thought.
 ∞∞ Enhancing999 (talk) 15:16, 27 August 2024 (UTC)[reply]
Even if galleries weren't a dead end on mobile they aren't well developed in most (if not all) cases and therefore (at least IMO) are inferior to categories. So they shouldn't be the main thing being linked on Wikidata's data end. Arguing otherwise just denies the reality of the thing. I think it would be totally valid to revisit the question of which one to link to if or when galleries on here stop being mostly worthless though. But them being dead ends on mobile is the least of the issue with them at this point. --Adamant1 (talk) 15:31, 27 August 2024 (UTC)[reply]
Agree but to add to that: galleries are linked from category pages in well-visible ways (often the only item in the pages or in a subcat that is sorted at the very top) so I wouldn't say it's the least of the issue with galleries. Afaik there is no Wikidata property for galleries but only one value for WMC that can be reached from the respective Wikipedia article when clicking on Tools->Wikimedia Commons or clicking the link in the Commons category template which usually is a category but sometimes is a gallery page with afaik no query that shows all wikidata items with a gallery instead of a category set... Prototyperspective (talk) 17:00, 27 August 2024 (UTC)[reply]
Afaik there is no Wikidata property for galleries @Prototyperspective: apparently it's P935 and there's over 100,000 uses of it. Although I've only ran into it a couple of times in like 7 years of editing on both projects. So I don't blame anyone for not knowing it exists. Clearly it's under used. Maybe adding it and other properties related to Commons on Wikidata can and/or should be a project for editors on here who care about that at some point. --Adamant1 (talk) 18:58, 27 August 2024 (UTC)[reply]

Closing

User:ReneeWrites has declared that the original issue has been fixed, and renewed the Commons:Deletion requests/Carl Johan Adlercreutz. So I think:

  1. This discussion can be closed. Whoever wants to discuss further about Wikidata items including links to gallery pages, can do so on Wikidata:Wikidata:Requests for comment/Proposal to create a separate section for "Commonswiki" links; (sorry for the wrong link, thanks Dogfennydd for the correction).
  2. The conclusion is that it is OK for gallery pages with just one photo, or otherwise do not meet the criteria of gallery pages, to change the interwiki links to Commons in the Wikidata item, from the gallery page to the Commons category. @AFBorchert: Do you agree? How can this conclusion get known to other administrators who delete gallery pages?

Thanks all for your contributions! --JopkeB (talk) 15:31, 27 August 2024 (UTC)[reply]

Just saw this --- I would say, more specifically, that P935 should never point to a gallery with one image. If you remove those from Wikidata, I think the problem is solved (even if the gallery doesn't get cleaned up at Commons).
@Adamant1: I think we should be using {{Gallery page}} more often, which explicitly links to the corresponding category and I believe shows up on mobile. That solves the "dead-end" problem you mention. — hike395 (talk) 21:31, 27 August 2024 (UTC)[reply]
I think someone else mentioned it originally, but using {{Gallery page}} sounds like a fine solution in absence of something better. I actually haven't seen it used in galleries much when it probably should be anyway regardless of the issue with them being dead ends on mobile. So there's clearly things we can and should to improve galleries on here. --Adamant1 (talk) 21:35, 27 August 2024 (UTC)[reply]
  • It would be very useful if somebody created a query that shows all Wikidata items that have a gallery page set for "Commons" in "Multilingual sites".
  • A query that lists all gallery pages without {{Gallery page}} would also be useful.
Prototyperspective (talk) 22:06, 27 August 2024 (UTC)[reply]
I don't think it's to accurate but if you search for "P373 -P935" (which is the property for "Commons category" minus the one for "Commons gallery") on Wikidata it gives 5,577,195 results. Although the exact number is probably much lower then that because not every topic on Commons with a category will have a corresponding gallery to begin with. --Adamant1 (talk) 00:16, 28 August 2024 (UTC)[reply]
(Out of scope of this discussion) Now we are spouting wishes for queries with galleries: I would like to have one for gallery pages that have no gallery category (that is: without at least one subcategory of Category:Gallery pages), to reduce gallery pages without such a category. I now use Petscan, but Petscan is rather new for me and I only know how to search for gallery pages WITH {{Gallery page}}, but I guess there are far more without this template. (For me the problem is, that on the tab "Page properties" is no checkbox for galleries or pages, so you have to make a workaround.)
To search for gallery pages after I have created a new gallery category, Gallery search is great for finding galleries about a subject. But I do not know how to search there for gallery pages without a gallery category. (For me the problem here is, that I do not know a way to exclude subcategories of Category:Gallery pages, what is possible in Petscan.)
Does anybody know how to search for such gallery pages? JopkeB (talk) 08:30, 28 August 2024 (UTC)[reply]
  1. The gallery page discussed here, has been deleted.
  2. @AFBorchert: Still one  Question: How can the conclusion (It is OK for gallery pages with just one photo, or otherwise do not meet the criteria of gallery pages, that is nominated for deletion: to change the interwiki links to Commons in the Wikidata item, from the gallery page to the Commons category) get known to other administrators who delete gallery pages? Could you please tell us?
JopkeB (talk) 12:23, 28 August 2024 (UTC)[reply]
@JopkeB: Quote from COM:G: Galleries with only a single image are permitted if they highlight an image which has been elected by the community as a featured picture, quality image, or valued image. From this I conclude that in cases where we have just one random image, we delete it. But care should be taken to update the Interwiki links where necessary. In cases with no media at all, speedy deletion criteria COM:GA1 applies. --AFBorchert (talk) 12:40, 28 August 2024 (UTC)[reply]
Nevertheless, a gallery of one is ridiculous. Perhaps if galleries are to be used they should feature the best examples of all the pictures in the category.
I personally don’t want them, I want the category, they just get in the way. I want immediate access to parent categories.
I see no justification for them, unless there are 50 images or more in a category. Broichmore (talk) 13:35, 28 August 2024 (UTC)[reply]

@JopkeB: The petscan command to find gallery pages without {{Gallery page}} is here: [9]. I see >60,000 of them. — hike395 (talk) 01:12, 29 August 2024 (UTC)[reply]

Thanks. But there I only see gallery pages WITH gallery categories and I need the ones without such a category. To solve that I moved "Gallery pages" from Categories to Negative categories, but then I get an error message. How to solve that? JopkeB (talk) 03:50, 29 August 2024 (UTC)[reply]
Petscan cannot do an exhaustive search over all galleries: it requires some root category and depth to scan. In addition, it gives an error message if you try to scan more than 500,000 categories. The best I can do is this, which searches the 3 layers below Category:Topics which is a reasonable place to start. That give 430 galleries that have not yet been categorized under Category:Gallery pages. — hike395 (talk) 04:16, 29 August 2024 (UTC)[reply]

Thank you to all the 2024 Summer Olympics photographers!

Thank you to all the Commons contributors who went to the 2024 Summer Olympics, took pictures and uploaded them to Commons! Thanks to your work, a lot of Wikipedia articles now have photographs of events and sportspeople. These contributors are: @Aeltegop, @AlSepPhoenix, @Anthony Levrot, @Bruno Barral, @Chabe01, @Citizen59, @Daieuxetdailleurs, @DarDarCH, @Eponimm, @Felouch Kotek, @FreCha, @GFreihalter, @Grunn050, @Ibex73, @Jmmuguerza, @Kuberzog, @Kyah117, @Like tears in rain, @Lomita, @MFonzatti, @Nicolas22g, @Pronoia, @Ruyblas13, @Rz98, @Sebleouf, @Superbenjamin, @Titlutin, @VVVCFFrance, @Xenophôn, @Xfigpower, and @Zen 38. And I've likely missed a few. Feel free to add to them to this thread. Cryptic-waveform (talk) 13:40, 27 August 2024 (UTC)[reply]

You're welcome. --FreCha (talk) 17:42, 27 August 2024 (UTC)[reply]
Didn't have any effort to do as I'm working close to it. With pleasure ! Kyah117 [Let's talk about it!] 21:38, 27 August 2024 (UTC)[reply]

Massive backlogs are now the norm

Looking at Commons:Deletion requests, there are currently nearly three thousand deletion discussions that are past due for closure. Commons is teetering on being a failed project due in part to the lack of administrators. There simply is too much work for the available pool of administrators. This problem isn't getting better. It's getting worse.

So, why are we allowing new uploads to the project from anyone which just exacerbates this problem? The status quo is failing. --Hammersoft (talk) 14:03, 27 August 2024 (UTC)[reply]

Category:Items with disputed copyright information is another example of backlogs. And it's hard to tell how well new uploads are reviewed. --EugeneZelenko (talk) 15:14, 27 August 2024 (UTC)[reply]
This is a real problem. Aside from more administrators, what do you propose? What should be done to limit bad uploads (for copyrights or other reasons)? JopkeB (talk) 15:37, 27 August 2024 (UTC)[reply]
Maybe more agressive and pro-active use of CheckUser? Trade (talk) 17:18, 27 August 2024 (UTC)[reply]
I forgot where I read it, but I think CheckUser has to be extremely rare because of the nature of the thing. --Adamant1 (talk) 18:03, 27 August 2024 (UTC)[reply]
Then almost every other Wikiproject should have the same high rejection rate. Except they dont. Its just Commons Trade (talk) 20:44, 27 August 2024 (UTC)[reply]
I haven't participated in Wikipedia for at least a few years but from what I remember they have pretty high standards to. But then they also have way more users and bad actors because of that. Plus it's just seems easier to come up with evidence of socking on there. So it just makes sense that they would have a higher CheckUser rate. I know from my own experience that there's been at least a couple of times where I wanted to file a CheckUser report on here but ended up not doing one because there just wasn't enough of a paper trail in both cases to justify it. I feel like there probably would have been if it had happened on Wikipedia either time though. --Adamant1 (talk) 20:50, 27 August 2024 (UTC)[reply]
There's been at least a couple of discussions lately about expanding and/or improving the criteria for speedy deletion. It seemed like none of them went anywhere at the time, but I think that would a lot with the backlog. As would making it easier for people to nominate images for speedy deletion to begin. As I guess its not an option on the side panel right now outside of clear copyright violations when it really should be. We could also use more admins, but I the standards are currently to high and I doubt they would work in that area anyway. Really you could argue current admins not dealing with deletion request is as much of or more of an issue then us just not having enough of them. There's no point in having more admins if they aren't going to work in the areas where they are most needed to begin with though. --Adamant1 (talk) 15:54, 27 August 2024 (UTC)[reply]
The backlog was much lager some month ago. If we need an urgent action we should block IP edits to prevent their spam and get time to work on deletion requests. GPSLeo (talk) 15:56, 27 August 2024 (UTC)[reply]
I had thought about that but it doesn't seem like there's any support to block IP edits on here. I totally agree that they should be blocked though. IP editors are a massive time suck in general. --Adamant1 (talk) 16:23, 27 August 2024 (UTC)[reply]
How exactly is blocking IP's supposed to help in any way? The issue is with people uploading copyvio. IP's obviously cannot upload anything in the first place Trade (talk) 17:16, 27 August 2024 (UTC)[reply]
But if we need 6 admin hours per day to check and clean up IP edits we can not use these 6 hours to handle deletion requests. It is simply a question of admin time availability. GPSLeo (talk) 17:50, 27 August 2024 (UTC)[reply]
Aside from what GPSLeo says I work in the area a lot and IP editors tend to either create a lot of meritless deletion requests or troll DR discussions. Obviously it would be a lot easier to deal with the back log if there weren't as many clearly pointless deletion requests being created to begin with. --Adamant1 (talk) 17:53, 27 August 2024 (UTC)[reply]
It's a bit odd for random IPs new to Commons to be so familiar with the DR procedure Trade (talk) 20:46, 27 August 2024 (UTC)[reply]
Most of the time their comments amount to something along the lines of "not own work?" Otherwise I'd agree with you. There are some times where there's clearly socking involved or the IP editor is probably a previously blocked user though. Both of which is all the more reason to block them IMO. It's purely conjecture on my part, but I highly doubt most IP editors on here are participating in the project that way for legitimate reasons. --Adamant1 (talk) 21:13, 27 August 2024 (UTC)[reply]
Agree with Adamant1. I also see too often violation and other non-constructive contributions by IP adresses, also in discussions. It takes a lot of time to fix them. Why do IP's have nearly the same rights on Commons as accounts have? My proposal: Restrict their rights. They should just be allowed to read things on Commons and have no possibility for violation. They are already excluded from uploading, why not from editing as well? If they want to start or join discussions, nominate files for deletion and so on, then they should use an account, like the rest of us. JopkeB (talk) 06:36, 28 August 2024 (UTC)[reply]
The deletion requests would be much easier to close if more people participated. Trade (talk) 17:19, 27 August 2024 (UTC)[reply]
Less than 3.000? Good job then, just a few years ago it used to be over 6.000. --Rosenzweig τ 15:59, 27 August 2024 (UTC)[reply]
3000 sounds like what @Yann does in a blink. ;) Thanks btw.
 ∞∞ Enhancing999 (talk) 20:48, 27 August 2024 (UTC)[reply]
Is the problem really getting worse? As in, are the various backlogs growing faster than they're shrinking? This argument came up on enwiki with regard to unsourced articles recently and it turns out that though there are an enormous number of those, they are being taken care of faster than new ones are being created.
I suspect something similar is going on here, especially since there is over a decade's worth of files to go through. To use another backlog as a comparison point, there are roughly 128,000 uncategorized files uploaded in 2024. Which is bad, but more than 128,000 files have been removed from the uncategorized backlog from 2021 and 2023 alone. Gnomingstuff (talk) 00:24, 28 August 2024 (UTC)[reply]

" Commons is teetering on being a failed project" if backlogs mean a project is teetering on the edge of failure, the virtually all Wikimedia projects have been teetering on the edge of failure since their inception. Yes, it would be good to do better. No, this is not a crisis, let alone a death knell.

Do not forget you need a native English speaker who is at the same time a railway fan (not necessarily a railway expert, but has knowledge above the average) to close this discussion. I just looked at it and I can not close it. I can not say a difference between "close" and "closed" in this case. Ymblanter (talk) 21:02, 27 August 2024 (UTC)[reply]
More admins would help, the issue is really active admins. Among the 183 admins, only 129 have done any admin action during the last month, and only 64 have done more than 20 admin actions during the same period. Yann (talk) 21:10, 27 August 2024 (UTC)[reply]
A CFD is not a Deletion request, so I think it is out of scope of this discussion. CFD's cannot be closed just by administrators, but every experienced editor can do so. JopkeB (talk) 06:07, 28 August 2024 (UTC)[reply]

Category for "buses in" and "buses of"

We have for example category for "Buses in Warszawa" and "Buses of ZTM Warszawa" included in "Buses in Warszawa", but "Buses of ZTM Warszawa" can go further than just Warszawa, or it can go for exhibition in Berlin etc. so I think we should create category for "Buses of ZTM Warszawa in Warszawa" and later if we have pictures of buses outside Waraszawa we could create also category for "Buses of ZTM Warszawa in Berlin". Note: I replaced word "Warsaw" with "Warszawa" for simplification and example is hypothetical but is quite common in case of other operators. What do you think? Eurohunter (talk) 17:02, 27 August 2024 (UTC)[reply]

I don't have an issue with something like that in theory when its clearly justified by how images we have of subject. There just isn't enough images on here to make lot of these types of categories worth creating though and the whole category structure for images related to transportation is convoluted enough as it is. If anything we should be cutting down on the number of intersectional categories related to transportation. Not increasing them. I don't think categories based on the brand or operator of the bus by location are that useful anyway. No one finds images of buses based on what town they happen to be driving through once. --Adamant1 (talk) 17:17, 27 August 2024 (UTC)[reply]
@Adamant1: You can probably find buses of PKS Poznań in Gdańsk and Warsaw so that's more transparent example, but if we don't have "base category" for "Buses of PKS Poznań in Poznań" people will be adding pictures of buses of PKS Poznań all over Poland for "Buses of PKS Poznań", so in case of city buses we can lose this if there are a few photos outside of "main city" with "buses in Poznań" as parent category. Eurohunter (talk) 17:32, 27 August 2024 (UTC)[reply]
I don't see how we'd be losing that if there are normal "buses in location X" categories with the operator being involved that the images can be put in. Someone not adding appropriate categories to files is a different issue then if a specific category for "buses of X operator in Y location" should exist or not though. Regardless, at the end of the day categories shouldn't exist purely act as stores of mundane facts and I'd say that's how they would be used in this case if PKS Poznań operators buses in other places in Poland outside of Poznań as part of their normal routes. Like if you were to have a couple of image of PKS Poznań bus in the Antarctic cool. Maybe create a category for that because it's not where they usually operate.
But if route 2 regularly goes to Warsaw as part of their daily operating schedule then there's nothing unique, notable, or subject defining about that. We have file names and descriptions for a reason. You can't just take everything from either one and make a 1/1 recreation of them in short hand with category names. There's no reason there can't just be a category for the route, "buses by location X", and then images be put in both categories depending on the circumstances and without the operator being involved since it's kind of a given that they operate the specific route. Then if someone wants to know the exact street address of where the bus was at the second the image was taken they can find out by reading the file name or description. It's kind of a given that any bus on "X route" will be going to "Y location though. So I don't think there needs to be any more categorization beyond that. --Adamant1 (talk) 17:47, 27 August 2024 (UTC)[reply]
@Adamant1: I think if we would have technically at least two photos of each city during whole route of PKS Poznań to Gdańsk we could create category for "PKS Poznań route to Gdańsk" with "PKS buses in..." for each city. There are even categories for colour of buses, so I think location would be more important, especially if in many cases it has a parental category "Buses in...". Eurohunter (talk) 18:09, 27 August 2024 (UTC)[reply]
Two photos of buses operated by PKS Poznań in different cities isn't enough to justify it. How many total photos of buses operated by PKS Poznań by city are there? Like how many images of buses in Gdańsk operated by PKS Poznań are there on here and really why waste people's time asking about it on the Village Pump to begin with if your just going to stick your fingers in your ears and ignore people's opinions about it? --Adamant1 (talk) 18:14, 27 August 2024 (UTC)[reply]
@Adamant1: If there are two photos for location then category is eligible. We categorise files by date, location and other possible solutions (using common sense). Location is quite important and it's helpfull. I don't think it's waste of time. It's just certain way of working and yours is different - the more voices we have here the more opinions we have. Eurohunter (talk) 20:37, 28 August 2024 (UTC)[reply]
I don't think that's the standard. There's other things involved in deciding in if its OK to create a cateogry for something or not. We'll have to agree to disagree though. Its clear you don't really care about other opinions.
the more voices we have here the more opinions we have. Sure and I'm just sharing mine. The last time I checked I can do that. Maybe don't ask a question the Village Pump next time if all your doing it for is agreement about your position though. --Adamant1 (talk) 20:46, 28 August 2024 (UTC)[reply]
  • "In" specifically means location. "Of" is broader, but can be place of origin. So for example a bus made in Country A by Manufacturer B, photographed in Country C, would be a bus "in" C, but could be "of" A or B. There can be times when both constructions can be useful. -- Infrogmation of New Orleans (talk) 20:52, 28 August 2024 (UTC)[reply]

Reredos or reredoses?

We have Category:Reredos and a number of subcategories; many of the latter used to use "reredoses", but have been renamed.

Wiktionary and a number of other online dictionaries give the plural as "reredoses", and not "reredos". Which should we use? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:54, 27 August 2024 (UTC)[reply]

Google gives only 17,200 hits for "reredoses" vs. 221,000 for "reredos". For Spanish it is 166 vs. 12,900 (which suggests that plural is very uncommon in its native Spanish; for English 23,000 vs. 321,000, so apparently it is actually more common for English-speakers to pluralize it this way.
Make of that what you will. I suspect that a prescriptivist would favor reredoses; I am not sure I've ever actually heard anyone say that rather than just use the singular form when they mean the plural. Then again, every time I need to distinguish reredos and retablo, I need to look it up. - Jmabel ! talk 00:36, 28 August 2024 (UTC)[reply]

Toilet type

This type of toilet I have only recently seen. I looks like a vandalresistant toilet. The two places where I have seen it where in Austria and Luxembourg. Both in places without payment and Surveillance staff. How should we classify these toilets? Smiley.toerist (talk) 22:40, 27 August 2024 (UTC)[reply]

What comes to mind for me is Sanisettes. Unless I missed it there doesn't seem to be a general category for self cleaning bathrooms though, which I'm kind of supprised about. --Adamant1 (talk) 22:52, 27 August 2024 (UTC)[reply]

Is File:P103013PS-0384 (10596687253).jpg actually PD?

The file is tagged with {{PD-USGov-POTUS}} but that seems at odds with the copyright statement in the exif data:

This official White House photograph is being made available only for publication by news organizations and/or for personal use printing by the subject(s) of the photograph. The photograph may not be manipulated in any way and may not be used in commercial or political materials, advertisements, emails, products, promotions that in any way suggests approval or endorsement of the President, the First Family, or the White House.

Which takes precedence? — Preceding unsigned comment added by RoySmith (talk • contribs) 23:29, 27 August 2024‎ (UTC)[reply]

I don't see how this can be PD. If the photographer is an employee of the federal government there may be no copyright on their contribution to the photo, but clearly it is a derivative work, and I can't see why the sculptor would lose their rights just because a federal employee photographed the sculpture. - Jmabel ! talk 00:41, 28 August 2024 (UTC)[reply]
(Separately) I believe the thing about endorsement is standard boilerplate, but it's a non-copyright restriction. Just like the band The Presidents of the United States of America got in a bit of trouble for making commercial use of a photo of themselves with Bill Clinton. - Jmabel ! talk 00:44, 28 August 2024 (UTC)[reply]

August 28

Uncategorized categories, except infobox

Report Special:UncategorizedCategories provides additional information to Special:UncategorizedCategories. Ideally it would be updated daily. Regular updates seem to make it easier to maintain it.

Report UncategorizedCategories with infobox has categories that don't appear there as they are in Category:Uses_of_Wikidata_Infobox_with_no_item, meaning, there is only an empty {{Wikidata Infobox}} on the category, but no other parent categories. Eventually the two reports might be merged.

For both Intro Special:UncategorizedCategories lists ways to take care of these categories.
 ∞∞ Enhancing999 (talk) 11:28, 28 August 2024 (UTC)[reply]

Awesome! This is very useful. It implements one part of the two I requested here. Could you also create a report for categories with only redcategories? Then all categories practically without categorization would show up on some report. A next step thereafter I think would be to have some bot identify cats missing cats and making e.g. Suggested Edits category suggestions, for example using data of the corresponding WP article in a way that makes these suggestions constructive. Such bots would be especially useful for experienced users adding categories to the categories on these reports and greatly reduce the time required for that and the backlog size.
Some change proposals:
  • could you rename "top users" to something like "users creating most uncategorized categories"? (this feature also ties in somewhat with the gamification-like feedback mechanisms discussed here)
  • it would be good to link to these reports from here and other places where Special:UncategorizedCategories is linked from
  • it would be good to link to these reports from Special:UncategorizedCategories itself
Prototyperspective (talk) 12:46, 28 August 2024 (UTC)[reply]
Thanks for the input. Feel free to link the reports from places you think it's useful. I made an edit request to add it to Special:UncategorizedCategories at MediaWiki talk:Uncategorizedcategories-summary.
For actual implementation of additional reports, you might want to use Commons:Bots/Work_requests. Special:WantedCategories exists and seems to be long (5000 categories wanted 14 and more times). It also has the advantage that it gets updated when a category is created.
Maybe Category:Pages with coordinates also includes categories that aren't categorized otherwise. Possibly a few other categories are similarly suboptimal.
 ∞∞ Enhancing999 (talk) 13:01, 28 August 2024 (UTC)[reply]
Briefly, as for Special:WantedCategories those only show the redcats but not categories with only redcats. This is very different and doesn't really address the same problem but if it did then in a very different way. For example, many of these cats only have a nonexisting category that is used only once (namely in that category) while this shows the top XYZ by number of use and currently only shows categories with at least 14 items. Prototyperspective (talk) 13:14, 28 August 2024 (UTC)[reply]
Oh, something like this (except that 4 of 13 exist).
 ∞∞ Enhancing999 (talk) 13:21, 28 August 2024 (UTC)[reply]
That's a separate subject and not necessarily a problem. Prototyperspective (talk) 13:24, 28 August 2024 (UTC)[reply]
If it's something else, do you have a sample?
 ∞∞ Enhancing999 (talk) 13:26, 28 August 2024 (UTC)[reply]
It's categories that have nothing but nonexisting categories. I don't have an example now but could add one if I find one but I'd suggest simply categorizing a category missing categories in such a way for a test-case. There's many of these. Also note that categories having nothing but nonexisting categories and Wikidata infobox meta categories should also show up in some report. The two examples I listed here (this and this) apparently are not included in your report so I think it still needs further work so it also includes these. Prototyperspective (talk) 13:34, 28 August 2024 (UTC)[reply]
Oh, it seems with "nonexisting categories" you mean categories that have the "hidden category" attribute set (visible on the second line). Generally all categories that are not topical categories. Category:Sinauli has four such categories (Uses of Wikidata Infobox, Uses of Wikidata Infobox with no image, Uses of Wikidata Infobox with maps, Pages with coordinates). The infobox sets 3 of them, MediaWiki the last one.
 ∞∞ Enhancing999 (talk) 13:40, 28 August 2024 (UTC)[reply]
No I don't!
The categories it has are all just meta categories set by the Wikidata Infobox and I thought that's what your report is about. Prototyperspective (talk) 13:43, 28 August 2024 (UTC)[reply]
The second report is about empty infoboxes only.
 ∞∞ Enhancing999 (talk) 13:47, 28 August 2024 (UTC)[reply]
Thanks for the info, all the samples I looked at didn't have any normal categories so can this report also be used for that and if not the title of the report is flawed and doesn't match what the report is about. It could be named "Report UncategorizedCategories with empty infobox" but I'd suggest changing it so it also shows items with non-empty infoboxes or creating and additional report "Report UncategorizedCategories with non-empty infobox". Prototyperspective (talk) 13:54, 28 August 2024 (UTC)[reply]
The intro defines the exact scope. For your request, maybe the infobox itself can determine if there are any other categories available. It's conceivable that a category with an infobox is correctly only in "hidden cats", so checking those isn't sufficient.
 ∞∞ Enhancing999 (talk) 14:00, 28 August 2024 (UTC)[reply]
What do you mean with "isn't sufficient"? There simply are many cases like the two examples that are practically without categories / missing categories but don't show up in reports because they have a few meta-categories set by the Wikidata Infobox. If there are cases where this is fine these are very rare and one could think about what to there once there are some examples of that where one can see how such can occur and maybe how they could be excluded from the report. The infobox itself can't determine that, it can at most add or suggest a few more categories but that's basically a separate subject and doesn't solve anything. Prototyperspective (talk) 22:37, 28 August 2024 (UTC)[reply]
BTW the "last user who edited the category" may not be the one who created it. Also, for the second report, it may have been disconnected from Wikidata since the last edit.
The default sort is by page_id, meaning newer categories appear first. The categories can be sorted by last edit date.
 ∞∞ Enhancing999 (talk) 13:14, 28 August 2024 (UTC)[reply]

August 29

Category descriptions

I'd like to establish some community consensus on what constitutes an appropriate amount/use of category descriptions. Categories that have to do with North Brabant often have large, self-referential descriptions with all manner of interwiki linking and use of external linkage that is not appropriate, for example Category:Geertruidenberg or Category:Heusden, North Brabant, or any of the places linked in the template above. Compare that to famous cities like Category:London or Category:Chicago, which have minimal descriptions by comparison.

Then there's subcategories. Category:Van Goghkerkje mentions it's at the Vincent van Goghplein 1, 4881 DG Zundert in the municipality of Zundert in the province of North Brabant in the south of the Netherlands. This information is then repeated in almost every single subcategory, including the metacat Category:Van Goghkerkje by year.

Category:Streets in Geertruidenberg mentions in the category description that this subcategory is for pictures of streets in the municipality Geertruidenberg in the province of North Brabant in the south of in the Netherlands. Category:Nature of Bergen op Zoom mentions in the category description that this subcategory is for pictures of nature and nature reserves in and around Bergen op Zoom in the province of North Brabant in the south of in the Netherlands. The category Category:Geography of Moerdijk mentions in the category description that this subcategory is for pictures of the geography in de gemeente Moerdijk in the province of North Brabant in the south of in the Netherlands.

Thousands of categories are like this, almost exclusively those in North Brabant. I'd like to start cleaning these up, but before I do I want to establish community consensus on where the line is drawn when something turns excessive so I know what to trim and what to keep.

My opinion is this:

  • No repeating of information that can be found in the category name ("The category "Streets of Geertruidenberg" is for pictures of streets of the municipality of Geertruidenberg...")
  • No repeating of information that can be found in an infobox
  • No repeating of information that can be found in a parent category
  • No external linking to personal websites, or other sites that would not be considered reliable sources on other Wikiprojects

ReneeWrites (talk) 07:36, 29 August 2024 (UTC)[reply]

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