Commons:Village pump: Difference between revisions

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Browse history interactively
← Older editNewer edit →
Content deleted Content added
VisualWikitext
m Bot: added daily section heading for September 05
Line 979: Line 979:


:OK, solved, I had "ImageAnnotator" disabled in Preferences-Gadgets, thanks and sorry for trouble [[User:JotaCartas|JotaCartas]] ([[User talk:JotaCartas|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 16:43, 4 September 2024 (UTC)
:OK, solved, I had "ImageAnnotator" disabled in Preferences-Gadgets, thanks and sorry for trouble [[User:JotaCartas|JotaCartas]] ([[User talk:JotaCartas|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 16:43, 4 September 2024 (UTC)

= September 05 =

Revision as of 00:00, 5 September 2024

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/11.

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 Hosting HDR images as JPEG with gain map 1 1 C.Suthorn 2024-11-01 07:41
2 Google's semi-censorship of Wikimedia Commons must end 34 11 ReneeWrites 2024-11-03 15:57
3 I messed up making a mass deletion request 2 2 RoyZuo 2024-11-01 18:57
4 Flickr license and license in embedded metadata differ 14 5 RobbieIanMorrison 2024-10-30 21:56
5 Your input... 13 5 Enhancing999 2024-11-03 21:53
6 https://ocr.wmcloud.org/ 6 5 Enhancing999 2024-10-31 21:33
7 Views through mobile phones 7 5 Prototyperspective 2024-11-03 12:28
8 Category:Musical groups by genre 5 2 Jmabel 2024-10-31 01:02
9 Almost 400k files need license review 25 10 Jmabel 2024-11-05 19:41
10 Obtuse bot created categories 14 9 Enhancing999 2024-11-03 10:46
11 Commons Gazette 2024-11 1 1 RoyZuo 2024-11-01 19:15
12 Derivative works (FOP etc.) 6 6 Enhancing999 2024-11-03 10:39
13 Special:Uploads/Claudiupt 1 1 Strainu 2024-11-02 10:19
14 Help needed with a new userbox template 1 1 David Osipov 2024-11-02 11:54
15 Provinces of China by month and year 3 3 RoyZuo 2024-11-02 23:58
16 Edit summary on project chat 6 4 ReneeWrites 2024-11-03 22:35
17 file description pages from IA Flickr stream 1 1 Enhancing999 2024-11-03 14:30
18 New page for establishing textured meshes on Commons 1 1 PantheraLeo1359531 2024-11-03 18:16
19 FYI 6 4 C.Suthorn 2024-11-05 16:37
20 New law in Costa Rica: "Public Domain of Information" 2 2 Jmabel 2024-11-05 19:45
21 Moscow State University Herbarium 1 1 Yann 2024-11-05 15:36
22 {{TOO-US}} 1 1 Trade 2024-11-06 12:24
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.
Turkey Beypazarı district Hırkatepe Village pump. [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 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 22

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: [1][2][3][4].
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 [5], 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]

Conclusions + proposals + questions

  • The question is: Is it allowed to rename categories with an English name to local language names?
  • Answers:
    • Local language names are OK for category names if:
      • there is no English name, or
      • there is a redirect from the local language name to the English name or
      • it meets the criteria of Commons:Categories#Category names (names for which the non-English name is most commonly used in the English language).
    • Categories with local language names are doubtful if:
      • it is not about a proper name, but about something else, like a function: Category:Taoisigh (prime ministers of Ireland) and Category:Chancellors of Germany (prime ministers of Germany) are in the rest of the world known as prime ministers. Though these local words may be well known in the UK, they are not in most of the rest of the world and they certainly do not meet the Universiality principle, which says that "Identical items should have identical names for all countries and at all levels of categorization."
      • names are hard to translate into English (then they should at least be transcribed to Latin script).
    • It is not OK if:
      • there was no CfD for (there was no CfD for this case)
      • the name is not in the language that has the most chance of being searched for (in this case that is English)
      • the name is not in Latin script.
    • Another solution is to put alternative names, in however many languages, into Wikidata.
  • Category:Heroes' Cemetery in the Philippines should not have been renamed to Category:Libingan ng mga Bayani.

Proposals

  1. Revert the renaming of Category:Heroes' Cemetery in the Philippines and let the local category have a redirect to the English one.
  2. Try to include the conclusions of this discussion in Commons:Categories.

@B25es, Seav, Geohakkeri, Jmabel, Nakonana, Adamant1, Enhancing999, Prototyperspective, MGA73, JWilz12345, Broichmore, and Immanuelle:

  • Do you agree with the conclusions?
  • Do you agree with the proposals?

--JopkeB (talk) 15:29, 30 August 2024 (UTC)[reply]

I thought we don't want "River of January" type of translations (easy to do)? The question for a reference for the past name of the category seems still unanswered. We do have it for the current category name (even in the category). We do seem to agree the "Category:Cemeteries in the Philippines"-category should remain in English.
 ∞∞ Enhancing999 (talk) 15:35, 30 August 2024 (UTC)[reply]
  • I think there is a big difference between "allowed" to rename and "a good idea" to rename. I understand "a good idea" as "we should" rename. I'm from Denmark and we have Category:Copenhagen and I think it should be left alone because there are more readers that know the city as Copenhagen than København. But if someone had named the category "Buy a harbour" then I would ofcourse agree that the original name was better just like I think "River of January" should be renamed.
I think both the conclusions and the proposals are fine. But I also live happily with the new name. Just don't start a mass rename of thousands and thousands of categories just to get local names. --MGA73 (talk) 16:01, 30 August 2024 (UTC)[reply]
  • Both conclusions and proposals make sense.
    Some understanding has to be used regarding those of us that not being proficient enough in English ignore how to say some things in English. Some categories written the best we can will pop up.
    Also when things may have an English name but it is not widely known even among native English speakers themselves, category names may be not as perfect as desired.
    I do appreciate when categories I have created are properly Anglisized, but category redirects from other languages are of great help.
    A long term plan/idea/intention to have something like Wikidata's Qs, where somebody writes iron, my wife reads hierro, and someone in Dodoma reads chuma, would be great. B25es (talk) 17:25, 30 August 2024 (UTC)[reply]

I certainly disagree with the conclusion that we should call the Chancellor of Germany the "prime minister of Germany". The term "Chancellor" dates back at least to the 1870s (and may have been used in Prussia before that, I'm not sure). It is simply the correct word in English (the German being Kanzler). The Germans do not use the word Kanzler to refer to comparable positions in other countries (e.g. they would not refer to the Prime Minister of the UK as a Kanzler, they would use Premierminister. It is simply not the same title, even if the role is similar. - 19:11, 30 August 2024 (UTC) — Preceding unsigned comment added by Jmabel (talk • contribs) ‎‎ (UTC)

Maybe chancellor would be an appropriate term for historical figures who traditionally called that, but I don't anyone outside of Germany uses the term these days. Like I know Hitler was called a Chancellor in Germany during World War 2 but if I do a search for him Google there's plenty of sources, including Google's information panel that calls him a Prime Minister. But then conversely the Wikipedia article for the role is called "Chancellor of Germany." So...There should be some standard and at least IMO Prime Minister makes more sense for our purposes if for no other reason then universality. I don't think it would make sense or work if he had diifferent terms for political appointees based purely what they are called locally regardless of if there's a universally recognized term for the role or not. Categories mainly (if not completely) exist as a way to organize images and naming them based on universality is clearly the best to do that regardless of if its 100% acccurate in every single instance. --Adamant1 (talk) 20:41, 30 August 2024 (UTC)[reply]
"Chancellor Angela Merkel" (in quotes) gets 1,880,000 Google hits. "Prime Minister Angela Merkel" gets a mere 5,940. Rather more recent than Adolph Hitler (also held the office rather longer), I'd say a 30:1 ratio suggests that the term is quite current. And since both "Chancellor" and "Prime minister" are specifically English-language, this should be specific to English. - Jmabel ! talk 21:59, 30 August 2024 (UTC)[reply]
@Jmabel: With Hitler it's 60,600 results for "Chancellor Hitler" versus 6,550,000 for "Prime Minister Hitler" and as I've already said that's even with him being called Chancellor in Germany at the time. So it clearly depends. You'd have to agree it would be pointless to argue about which term should be used used based on who the particular head of state was at the time. "Well, my German head of state has 6 million results on Google for Chancellor and yours only has 60 thousand for Prime Minister. So clearly the category should be named 'Chancellor'!" Not to say you'd do that, but I do think it's a case where it would just be better to go with the university principle instead of trying to determine how to name the category based on a game of one upmanship over who's favorite term for a head of state gets more results on Google Search. --Adamant1 (talk) 22:47, 30 August 2024 (UTC)[reply]
@Adamant1: I'm pretty sure you didn't use the quotation marks in doing that Google search. Obviously, Hitler would often be mentioned on the same page as some prime minister. But with quotation marks I get and 59,700 for "Chancellor Hitler" and only 9,440 for "prime minister Hitler", and even the latter include some more-or-less false positives: right near the top I see things like, "To the British Prime Minister, Hitler complained…" or "On May 13, 1940, Churchill gave his first speech as. Prime Minister. Hitler invaded France…" - Jmabel ! talk 23:23, 30 August 2024 (UTC)[reply]
@Jmabel: Weird. I thought I had. It looks like I probably left out the leading quotation mark though. My bad. --Adamant1 (talk) 23:26, 30 August 2024 (UTC)[reply]
If we are insisting that we use strict English for the cemetery in question (despite the Tagalog name being extensively used in English sources [see above]), then there is still the question of which English translation should be used. Should it be the original "Heroes' Cemetery", or "Cemetery of Heroes" or "Cemetery of the Heroes"? All three are acceptable English translations of the official name, but I prefer any of the two latter names as these more closely resemble the official name (this is like preferring "River of January" instead of "January River" for Rio de Janeiro). As for disambiguation, do we append "in the Philippines" as with the original category name, or use a parenthetical "(Philippines)" which seems to be the convention? —seav (talk) 22:32, 30 August 2024 (UTC)[reply]
At least in regards to the first part of your message, probably the best way forward at this point would be to revert the edit that changed the name and then someone can open a CfD to figure out what the best option is from there. It's pretty clear from this that the name shouldn't have been changed without there being a CfD first though and at least IMO figuring out what is to go with instead is probably out of scope of this conversation. --Adamant1 (talk) 22:55, 30 August 2024 (UTC)[reply]
I agree with Adamant1 about reverting. And, @seav, I intended "River of January" as a reductio ad absurdum, not a serious proposal. In English, the city in question is universally called either "Rio de Janeiro" or just "Rio". This is never turned into English words. - Jmabel ! talk 23:29, 30 August 2024 (UTC)[reply]
Yes, I know that "River of January" wasn't a serious suggestion, but I simply used it as an example of which of several possible English translations ought to be used if we are translating a name. — seav (talk) 00:39, 31 August 2024 (UTC)[reply]
I don't think anybody tried to do a literal translation of "Rio do J.", but occasionally I come across similar ones, where it's likely that Commons is the sole source for that name. I could name one or the other, but I don't want to embarrass the user who did try to do so. If you find a bad translation of mine, feel free to cite is as a negative example.
Obviously, I don't think there is an issue to provide a literal translations in the description.
For the cemetery, I agree we should have a proper discussion on CfD, especially as the previous name was the result of one.
 ∞∞ Enhancing999 (talk) 11:51, 31 August 2024 (UTC)[reply]
In the UK, the German prime minister is always referred to as the chancellor, as is his Irish equivalent the Taoiseach. Broichmore (talk) 13:18, 31 August 2024 (UTC)[reply]
In passing, I've just looked at Category:General Wali Kothi, who would believe this is actually a building aka Star house, Tara Khothe, Tara Khothee, andd Lucknow Observatory. There will be other names and spellings too. Never mind the Hindi variants, and counting. You can bet your bottom dollar, that the locals call it Star House, or the old Observatory, terms not officially used since 1947.
Almost every Indian category suffers from the same malaise, and exemplify reasons why, English is the standard here. Broichmore (talk) 13:26, 31 August 2024 (UTC)[reply]

August 23

{{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]
I wouldn't take the 50MP thing at face value. My phone has a 50MP camera and it's impossible to take sharp pictures with. I suspect they're basically just upscaled versions of the default 12MP camera, which does take sharp pictures. ReneeWrites (talk) 18:17, 3 September 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]

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 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]

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: [6]. 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]
There may be a way of performing the search that JopkeB desires using Quarry. The SQL required is a bit intricate. If any other editor wants to help Jopke with their search, please feel free! — hike395 (talk) 13:41, 29 August 2024 (UTC)[reply]
@Hike395: Thanks for the explanation, your research and your suggestion to use Quarry. But this tool is indeed too complicated for me. If anyone would like to help me: please do. The request is: A list of gallery pages that have not at least one subcategory of Category:Gallery pages (all the way down). JopkeB (talk) 14:52, 29 August 2024 (UTC)[reply]

Thank you to all the 2024 Summer Olympics photographers!

And this is my first "Quality Image" here on Commons. --FreCha (talk) 12:03, 31 August 2024 (UTC)[reply]

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]
You're welcomeǃ Hope there will be a lot of great pictures on Commons for Paralympic Games tooǃ MFonzatti (talk) 21:00, 1 September 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]
The larger Wikipedia projects are in my experience much more strict in almost all areas compared to Commons. ReneeWrites (talk) 18:12, 3 September 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]
When deletion discussions remain open essentially forever, when backlogs remain in the thousands across a number of types, when copyright violations are allowed to sit on the project indefinitely, then yes I would call this a failed project. We are not able to effectively police ourselves, and the incoming level of problematic files overwhelms existing ability to deal with it. --Hammersoft (talk) 17:36, 1 September 2024 (UTC)[reply]
maybe you can become a com:sysop and help? would you accept a nomination? RZuo (talk) 18:55, 1 September 2024 (UTC)[reply]
Frankly, I'm not active enough. I've seen various requests here, and noted concerns about activity levels. I doubt I'd meet expectations. Regardless, adding another administrator to the mix, especially at my activity levels, isn't going to help. I have other reasons as well, but this is really getting out of the scope of this discussion. --Hammersoft (talk) 19:18, 1 September 2024 (UTC)[reply]

I don't think we're teetering on anything, but we should all be able to agree the backlog is too big. Here's another reason it exists: DRs are often hard. Most admins aren't IP lawyers in one country, let alone every country, and there are a lot of really rough calls. Scope-based and people-based debates are also often hotly contested and difficult to assess. Beyond that, AfD on enwp is contentious and results in a lot of grief for closers, especially from newer users who don't understand the process. On commons, even many of the experienced users (or experienced users from other projects) routinely misunderstand the basics and make life sadder for commons admins. Back to the main point, however, there are definitely a lot of DRs that aren't that complicated which wait a long time to be closed, too, so more admins would help, at least. — Rhododendrites talk |  17:59, 1 September 2024 (UTC)[reply]

The same thing applies to CfDs. It just took me 2 days to deal with 4 of them because they all involved moving thousands of files and deleting hundreds of categories. Then there's ones that are extremely simple and can be closed in a couple of minutes. But its near impossible to deal with the later to any meaningful degree because of the time it takes deal with the former. Then there's a bunch that are clearly just complex to deal with for whatever reason. But its such a big mishmosh. Anyway, these things don't really scale. For them to be managable you'd need to have everyone on here participate and inforce clear time limits on how long the discussions can be open for. As well as cnsistantly keep the back logs down to a week or two. Otherwise its just going to be an unworkable mess. Its hard to say something should be closed a certain way after a week or two when it has a low turn out and an unclear outcome though. Sometimes it takes years just for someone to comment. So I don't know. There really is no single, easy solution. --Adamant1 (talk) 20:46, 1 September 2024 (UTC)[reply]
Just adding an example to go with my "DRs are often hard" comment above. I started looking through the oldest DRs and saw Commons:Deletion requests/Files in public domain featuring various Indian film artists post-1945. Taking action on that DR would involve a few dozen images and an understanding not just Indian copyright or US copyright but the interplay between the two. Even if we get more admins, the number of people who would feel confident weighing in on something like that are very few. Let's not have a discussion here about the correct outcome, though -- I'm just highlighting that these are hard, and while the act of closing a discussion may not take much time, attaining the level of understanding required to parse such a case would be very time consuming. It's no wonder nobody wants to do it. I wonder if there's a potential project for the WMF to undertake that would effectively create charts like COM:HIRTLE for media published outside the US and uploaded to Commons. Maybe even an interactive tool. — Rhododendrites talk |  20:56, 1 September 2024 (UTC)[reply]
I think for reusers and uploaders the open request signals there is a complex issue. Highly problematic uploads get nuked within hours.
 ∞∞ Enhancing999 (talk) 22:15, 1 September 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]
Thats two of us that think reredos is both singular, and plural, if that's the case then wikitionary needs updating. The OED doesn't specifically give a plural. A few examples imply it is both. The billets were heaped against the reredos, or plate of iron fixed against the back of the chimneys. In practicality there is only one for every item, be it an altar, a brazier, backing of a fireplace, a rood screen, or rear of an army. I've queried it with the OED. Regarding useage for in the 1600s it gives a variant of reredoes. I would leave it as reredos.Broichmore (talk) 12:26, 29 August 2024 (UTC)[reply]
How many of the 221,000 G-hits for "reredos" are for singular uses? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:03, 29 August 2024 (UTC)[reply]
No way to work that out. But I think the Spanish-language result is more revealing: only 166 uses of this supposed plural in the native language of the word. - Jmabel ! talk 18:46, 29 August 2024 (UTC)[reply]
But I think the Spanish-language result is more revealing: only 166 uses of this supposed plural in the native language of the word: Reredos isn't a Spanish word: the Spanish word is always retablo. Being a native Spanish speaker, I've never heard or read it in Spanish. All mentions to reredos in retablo Spanish Wikipedia article are English words (citations or etymology). Multilingual English Wiktionary only includes reredos for English language. As for retablo, the plural is retablos and is very commonly used. MGeog2022 (talk) 19:06, 29 August 2024 (UTC)[reply]
@MGeog2022: Ah, you are right: reredos is originally French (and originally had an a in front of it); I always mis-assumed it to be of Spanish origin. And I do see now that Spanish doesn't make the reredos/retablo distinction. Not a word that I have much day-to-day use for, not being a Catholic (or even a Christian), and I guess if I ever used it in Spanish no one corrected me. So my Google counts above are irrelevant, my apologies. (I still say reredoses doesn't exactly slip off the tongue, but I guess I won't object if there is a consensus to use it.) - Jmabel ! talk 19:26, 30 August 2024 (UTC)[reply]
And I do see now that Spanish doesn't make the reredos/retablo distinction: that's just why I was so surprised when I learned that English made this distinction :-) MGeog2022 (talk) 12:28, 31 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]

I'd say that the report is quite useful. Few (if any) false positives, so pretty much anything that shows up there needs some work. - Jmabel ! talk 18:48, 29 August 2024 (UTC)[reply]

Thanks. Updates are a bit complicated as infoboxes don't necessarily update when a category is connected to an item.
Commons:Report Special:UncategorizedCategories is now down to reasonable length (469 categories):
  • only 52 categories with 10 files or more (cat_size>9)
  • only recent empty categories (cat_size=0)
  • most users with many creations on the list have been made aware of the issue
∞∞ Enhancing999 (talk) 10:03, 31 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]

I guess most categories where the description would be relevant have {{Wikidata Infobox}}, which has all necessary information. Ymblanter (talk) 09:11, 29 August 2024 (UTC)[reply]
Maybe we miss something, but both Category:London and Category:Chicago currently have tons of category description, most can be found elsewhere, compared to Category:Van Goghkerkje. The later mentions an essential point that seems odd to mention without including a basic description before including stating the category name in the description itself.
Not sure how Category:Geography of Moerdijk can be compared negatively to Category:Chicago except when there is some bias involved. Stating the topic in local language(s) is fairly important.
Category:Chicago seems relatively bad as it has a large seal image in the center. It mentions "largest city in Illinois," which is marginally helpful.
A nice thing about Category:London is that it has that collapsed list that helps sorting. I find such Commons specific pointers fairly important.
 ∞∞ Enhancing999 (talk) 12:02, 29 August 2024 (UTC)[reply]
I was comparing the categories of Geertruidenberg and Heusden with those of London and Chicago, the latter of which have very succinct descriptions. London's is just one line of text. This is not about the navigation templates.
My critique of Category:Van Goghkerkje is that this information is repeated in most subcategories like Category:Van Goghkerkje by year and Category:Van Goghkerkje in 1969, etc.
And I was not comparing Category:Geography of Moerdijk to any of the above categories. I was making a stand-alone critique (that applies to Category:Streets in Geertruidenberg and others) that the category description just says what's in the category name, and that this is superfluous. ReneeWrites (talk) 12:26, 29 August 2024 (UTC)[reply]
Sorry about that then. Contentwise Category:Geertruidenberg or Category:Heusden, North Brabant don't compare that badly, though I don't think there should be two descriptions in Dutch and English.
If there are Wikipedia articles on the topic, references would generally not be needed. There was some discussion about this at Commons:Categories_for_discussion/2024/07/Category:Harp_Guitar_Form_3a.
The repetition at Category:Van Goghkerkje by year seems suboptimal, but that applies to the entire "by year" tree as well.
 ∞∞ Enhancing999 (talk) 12:52, 29 August 2024 (UTC)[reply]
There seem to be two types of descriptions (maybe one more popular than others), for a sample Category: "ABC":
  • 1. "ABC" is a ..
  • 2. This category is about media/photos/images related to/about "ABC", a ..
Personally, I prefer (1.), but 2. is not uncommon.
Content-wise, there are three types of descriptions about "ABC":
  • 1. no description
  • 2. Just repeat the title literally ("ABC")
  • 3. State something about ABC
Personally, I prefer 1 or 3.
 ∞∞ Enhancing999 (talk) 12:38, 29 August 2024 (UTC)[reply]
I agree with Ymblanter, wikidata supplies this info.
In the case, of all things North Brabant wikidata may be insufficient. I more than suspect, what you have here is an editor set in their ways since 2008, who finds Wikidata impenetrable, or even superfluous and persists without it. The cats are cluttered, I agree, and few (if any), will use these links. However, there’s no harm done here.
After all, this is supposed to be a project that anyone can edit.
I've beaten this drum about over complication, before, and I contribute to Wikidata (4000 edits), and it falls on deaf ears.
There's too much of high tech people here, making subject matter complicated and difficult to edit. I'm still waiting for Category:Gartenlaube (Magazine)'s open architecture to be restored. All new uploads there, are incompatible with the established closed off format.
Even today I discovered a source template for a major library that is no longer viable, because the library changed its catalog system rendering our source template into a link to an enormous pile of link rot. I fail to understand how people, make templates or such, then not put in place the mechanisms for continuous maintenance, or just walk away from them. Broichmore (talk) 13:21, 29 August 2024 (UTC)[reply]
I think I disagree with some premises here. Respectively, to the bullet list of opinions given by User:ReneeWrites:
  1. Don't forget the multilingual aspect of this. Repeating the category name in other languages can be very useful.
  2. I get what you say about the infobox, but sometimes a tight piece of prose is easier to skim quickly.
  3. Not everyone will be navigating down the hierarchy. I think it would be ridiculous, for example, for someone navigating up from a village to have to navigate many, many layers up the hierarchy to find out what country it is in.
  4. I could perfectly well accept the last point, with one possible exception: on topics where there is a serious limitation on commercially available material, it can be useful to have a link to a trove of NC content on (for example) Flickr. Not sure whether that is even an exception, maybe more of a clarification.
I'd also add: I think somewhat longer than usual descriptions are often useful for topics not likely to get a Wikipedia article. Example: Category:Court in the Square.
Further: the main problem with the subcats of Category:Van Goghkerkje is that there are this big batch of "by year" categories, mostly with one or two photos, and with little or no differences from year to year to suggest that is a useful way to subcat this. - Jmabel ! talk 14:03, 29 August 2024 (UTC)[reply]
Re. "the multilingual aspect" - surely that should be handled by Wikidata? Wikidata already has extensive support for multilingual desriptions of entities, and those descriptions should get pulled in by the Wikidata infobox. Writing those descriptions locally on Commons shouldn't be necessary. Omphalographer (talk) 19:16, 29 August 2024 (UTC)[reply]
Maybe you could explain how it should be happening for the samples where Renee writes that [Dutch] is super-flous.
 ∞∞ Enhancing999 (talk) 19:25, 29 August 2024 (UTC)[reply]
Regarding 4, I think this is a good point and a good way to add nuance to the topic. I'm not against removing all external links, though I didn't really clarify what I meant with "personal websites", and I think the exception you mention is reasonable. The website in particular I was thinking of was https://breda-en-omgeving.nl/ which you can find linked numerous times in the categories above (6 times in Geertruidenberg, 7 times in Heusden, as well as many other categories linked in the navigation template at the top). I'll also ping @Prototyperspective: because this is relevant to a thread below. ReneeWrites (talk) 11:45, 30 August 2024 (UTC)[reply]
  •  Support ReneeWrites opinion about it. Although I think Jmabel makes some good points, but I don't see them as mutually exclusive or applicable in every situation. Just to give an example from Jmabel's comment, don't forget the multilingual aspect of this, I'd say it depends on the topic of the category and what level down it is. For instance if we're talking about shoes and the person is browsing through Category:Shoes to find images of them then I don't think it's necessary or helpful to have the word "shoes" translated into every single language possible just because this is a multilingual project or whatever. It's a pretty good bet that most users know what a shoe looks like and has heard the word in English before. So there's zero reason to translate it or to have a description, in English or any other language. "Shoes are things you wear on your feet." No really? We don't need that in English, let alone 10 other languages.
Maybe you'll say that's a bad example since the category for shoes doesn't have a description to begin with though. But there's plenty of categories for extremely obvious universally known subjects out there that have totally pointless descriptions in multiple languages. So essentially I agree with ReneeWrites opinion about it. Although I think Jmabel makes a few good points, but multilingual thing shouldn't be a free pass to create descriptions that are otherwise totally pointless for whatever reason. --Adamant1 (talk) 17:22, 29 August 2024 (UTC)[reply]
@Adamant1: Again, though, you are assuming they got there by following the category tree from a more abstract category. They could just as easily have arrived from a category on an individual photo. - Jmabel ! talk 18:51, 29 August 2024 (UTC)[reply]
@Jmabel: Sure, but if someone gets to Category:Shoes from an individual photo of something that's not a shoe then there's other problems involved that categories having descriptions or not has nothing to do with. The only way to deal with people confused about where they are in the category structure at any given time is to categorize images properly. You can't make up for or fix that by putting "chaussure" at the top of a category. --Adamant1 (talk) 18:59, 29 August 2024 (UTC)[reply]
@Adamant1: "other problems involved" Well, yes. And if they are, for example, a Chinese-speaking editor, it would be useful if they don't have to to running way up the category hierarchy to work out that it was an error.
Some of this can be solved if there is a corresponding Wikidata item, but the more narrow the category, the less likely to have a Wikidata item, so the more important mere translation of the category name may be. - Jmabel ! talk 19:53, 29 August 2024 (UTC)[reply]
@Jmabel: I don't even disagree with that, which is why the used an extremely general topic like shoes as an exmple. It's certainly a different thing altogether the further down in the categories some goes. I'm not sure what the solution to that is but I still think ReneeWrites' proposal still makes sense with broader topics. Maybe there could be a cavit to it about how to handle categories for more obscure topics though. --Adamant1 (talk) 20:00, 29 August 2024 (UTC)[reply]
 Comment Generally agree except for the point 4. For example a link to a github repo may not be a reliable source at WP but still relevant and useful in a category about the software without a Wikidata infobox. Another problem is that several links in the Wikidata item don't show up in the infobox and something should be done about it there instead of adding a link also to official website (example: links to mediawiki.org in the "Multilingual sites"). Another caveat is that I don't know how Web search engine indexing works and that "No repeating of information that can be found in a parent category" is ambiguous – if you mean useful info that is not self-explanatory should be excluded in a category just because it's already in the parent category then I disagree (e.g. people may have gone directly to that cat from search results or a file instead of having seen the parent cat earlier). Prototyperspective (talk) 19:46, 29 August 2024 (UTC)[reply]
I don't think Github is a very good example. A Github page isn't a personal website, and it's perfectly acceptable to use as a source on Wikipedia (there's even a template for it: Template:GitHub). Github can't be used as a source to establish notability however. ReneeWrites (talk) 08:03, 30 August 2024 (UTC)[reply]
I think it's a good example because it illustrates well how websites considered nonreliable can be very appropriate and useful to have there. You agree that it can be appropriate so it's evidently a good example. That Wikipedia template is about external links, not references. I think it's used sometimes as a reference when the article subject is the software but it's not generally considered reliable. There are more possible examples like a category about some small organization linking to the organization's website and so on. There are many more cases where some website that would be considered unreliable would be very useful so at a minimum one would need to change that part, especially be considered reliable sources on other Wikiprojects, but I think it may be best if this point was removed or turned into a recommendation about what is usually (instead of always) the case. I'm still unsure what is meant with repeating info already in parent cat. However, I haven't seen any cases of such anyway but it doesn't seem like a good requirement. Prototyperspective (talk) 10:22, 30 August 2024 (UTC)[reply]
 Support Most of what has been said before. Thanks for starting this discussion. Maybe the four points of ReneeWrites just need some nuance. My remarks:
  • This does not concern only categories about the province of North Brabant, but for many location categories of the Netherlands. I have seen many of those descriptions elsewhere too.
  • For me they are redundant and annoying, but I am not the target group: perhaps to occasional visitors they might give useful information, especially if they are foreigners.
  • To limit obvious redundant information: No repeating of information that can be found in an infobox. But then there should be a Wikidata infobox. For subcategories like "in" categories (for countries, "streets in" and so on) and years, there usually are no, and should not be either (except for when there is a Wikipedia article).
  • I prefer "ABC" is a .. as well. The shorter, the better.
  • I agree with Jmabel: Repeating the category name in other languages can be very useful. Ever since I discovered in an English discussion about a Dutch subject that a Dutch participant had trouble discussing in English, I translate categories about the Netherlands into Dutch (unless there is a Wikidata item or it is a "by" category). And sometimes there is more explaning to do because the English word has no equivalent in Dutch (see for instance Category:Estates in the Netherlands) or the English word looks like a Dutch one, but means something else.
So in general:
  1. Every topic category should have either a Wikidata item or a description. Exceptions: if the category name is about a universally known subject (like "shoes"). In case of doubt: add a description in English, other languages are allowed too.
  2. No repeating of information that can be found in a corresponding Wikidata infobox.
  3. If there is no Wikidata item: Add descriptions to categories for countries that are not native-English speaking countries, preferably in their native language.
  4. Keep descriptions as short as possible. Add a link to the corresponding Wikipedia article in the native language if that is appropriate (especially in case of country categories). You may add links to other relevant websites that you trust if there is no Wikidata item and the website is within the scope of Commons (no avertising, and so on).
  5. 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...") should be avoided as much as possible. But sometimes it can be useful, even in this case: Geertruidenberg is a municipality AND a populated place. It is good to know for which one the category is (though it would be better to have it in the category name).
--JopkeB (talk) 07:41, 30 August 2024 (UTC)[reply]
What do you think of the samples Chicago and London?
 ∞∞ Enhancing999 (talk) 10:21, 30 August 2024 (UTC)[reply]

BTW, if anyone wants to see a good example of major overkill when it comes to a category description check out Category:Louvre Museum - Room 185 and scroll down past the infobox. I assume everyone here would agree that something like that is way to excessive. --Adamant1 (talk) 05:49, 31 August 2024 (UTC)[reply]

Not only is that wildly excessive, it seems like an unreliable basis for categorization. The museum can reorganize their collection; Commons shouldn't have to shuffle a bunch of categories around (or argue about what objects used to be where) when that happens. Omphalographer (talk) 06:15, 31 August 2024 (UTC)[reply]

French summer camp

These are children travelling to summer camp in organized fashion. The parents drop of the children at the station. Are there any categories for children traveling in groups?Smiley.toerist (talk) 09:31, 29 August 2024 (UTC)[reply]

This cerainly falls under Category:School trips, supervised by teachers. Broichmore (talk) 11:19, 29 August 2024 (UTC)[reply]
Not certain schools are involved. Quite a lot of organisations organize this in France (School kids have long vacations, the parents not so long): ucpa ufcv.fr capjuniors Smiley.toerist (talk) 11:29, 29 August 2024 (UTC)[reply]
Probably calls for some broader new category that would be somewhere under Category:Travellers and would have Category:School trips as a descendant. I agree that these are not typically school trips. This hypothetical new category should probably be broad enough to also include evacuations of children such as Category:Kindertransporte. - Jmabel ! talk 13:51, 29 August 2024 (UTC)[reply]
Organized children's trips? Trip, in the UK, would include the equivalent of summer camp. The original question was about a Summer camp, which is a destination, so travel, in this case. It's still a school trip, unless there is more background to change it. Broichmore (talk) 16:32, 29 August 2024 (UTC)[reply]
A school trip in the middle of the summer holidays? Sounds unlikely to me. Also, requiring the children to wear a piece of clothing that makes them easily recognizable in a crowd is something I have for more often encountered with summer camps than with school trips (the teacher being "expected" to be able to recognize their students). So, for me, this would rather be a category under Category:Summer camps in France. (Kudos for taking pictures of people actually using the Lorraine-TGV train station, especially with it being as remote as it is!) Poslovitch (talk) 19:50, 29 August 2024 (UTC)[reply]
When I was in the station, the guides where calling out the names from a list for the children to present themselves. So not school teachers. I asked the station staff and this station is often used for groups. Very accessible by road (highways) (And they dont have to drive to a centre of a congested town) There are public transportation buses going to the station, but these are little used. I myself travelled with a bus from Luxembourg city (minibus with 8 places and obligatory reservation) By the way the SNCF has a guided travel service for children travelling alone. They are dropped of by a parent/relative and on the destination picked up by another parent/relative (whose identity is checked). A service appreciated by parents.Smiley.toerist (talk) 21:02, 29 August 2024 (UTC)[reply]
The children are waiting for the TGV5470 (10:40 departure) to Rennes. This train stops at every station on the high speed line from Strasbourg to Massy TGV and then only stops at Mans and Rennes. The final destination is probably somewhere along the Atlantic coast. I put the pictures into Category:Summer camps in France. In the category there are no pictures of playing children, but only old buildings. I suspect that the European privacy rules and protection of children rules make pictures unavailable for the commons. Parents have to give permission to take group pictures of their child. There are more pictures of child activity in Category:Summer camps in the United States.Smiley.toerist (talk) 08:11, 30 August 2024 (UTC)[reply]
"people wearing an identital cap and travelling as a group" looks like a kind of group tour (package tour). RZuo (talk) 00:03, 31 August 2024 (UTC)[reply]

Two-sided image

What is the best way to upload images of the obverse and reverse of a single, double-sided work (like a postcard or trading card, for example)? I've uploaded entire pdfs before (see here, for example) but that seems excessive for something with just two halves. I suppose I could upload them as separate files but that seems strange. It seems like if I wanted to upload the reverse of this baseball card, for example, they should be part of the same File, no? I guess I could try and use one of these templates but I'm not sure. Please let me know your thoughts/advice. --Denniscabrams (talk) 14:12, 29 August 2024 (UTC)[reply]

I don't think there is an "ideal" way of doing this currently. One thing I've seen people do is upload the images as separate files, and in the "other versions" field link the other image. You could also upload it as a single image with the front and back op top of/besides each other, though those versions rarely get used in Wikiprojects as most people are only interested in the front of such cards. ReneeWrites (talk) 14:44, 29 August 2024 (UTC)[reply]
You could upload as a multipage tiff file i suppose. Bawolff (talk) 16:24, 29 August 2024 (UTC)[reply]
File:2nd Ave. north from between S. Washington St. and Yesler Way, ca. 1907 - DPLA - 3863fe08737d8a23848bb2b5ff579889 (page 1).jpg and the way it links to the reverse show at least one of what are certainly several good ways to do this. - Jmabel ! talk 18:56, 29 August 2024 (UTC)[reply]

When questioning "own work"

I see images tagged with {{No permission since}} when clearly the issue is "I don't believe this is 'own work'." Shouldn't we have a distinct tag for that? - Jmabel ! talk 21:51, 29 August 2024 (UTC)[reply]

+1 I've noticed this as well. It is currently the closest to correct tag that we have, but it's still not really correct. -- King of ♥ ♦ ♣ ♠ 21:58, 29 August 2024 (UTC)[reply]
How about {{No source since}}? An obviously invalid claim of own work fits the description of "...appears to have an invalid source listed". I agree that a more specific template would be helpful, though - something along the lines of "please update with the correct source/license, or send permission to VRT if it's really your own work". Omphalographer (talk) 01:03, 30 August 2024 (UTC)[reply]
I view {{No source since}} as having more or less the same problem (though per the phrase you cite, a bit less so). I still think a more specific template would be better, since this particular situation comes up so often. - Jmabel ! talk 04:52, 30 August 2024 (UTC)[reply]
Perhaps some template like "dubious source" could be even better, since there could also be misattributed files to other sources (source present in the file page, but it isn't the true source), not only for own works. MGeog2022 (talk) 12:24, 31 August 2024 (UTC)[reply]
I'd be OK with that; no reason for the template to be specific to "own work". - Jmabel ! talk 17:04, 31 August 2024 (UTC)[reply]
That sounds good -- DaxServer (talk) 17:57, 31 August 2024 (UTC)[reply]
The semi-speedy deletion templates should only be used for obvious cases that are recent uploads. For the "I don't believe this is 'own work'.", a regular deletion request should be used. Multichill (talk) 12:03, 1 September 2024 (UTC)[reply]

August 30

inconsistent database state

Hi, source Category:Files with coordinates missing SDC location of creation (49° N, 11°E) was moved (in May 2024) to target Category:Files with coordinates missing SDC location of creation (49° N, 11° E) by User:Multichill, but there are still >50000 files shown in the source category. Strange enough, this is not reflected by the file description, where the target category is shown, nor is a move reflected in the version history, e.g. [7]. A miracle I don't understand. A touch / nulledit helps to remove misscategorized files. Is there a way to fix this in a bulk operation for all files? Can someone fix this issue? best --Herzi Pinki (talk) 08:10, 30 August 2024 (UTC)[reply]

It's usual for categories added by templates or mediawiki itself.
 ∞∞ Enhancing999 (talk) 10:18, 30 August 2024 (UTC)[reply]
Ok, the behaviour is caused by {{Location}}. And it's usual, that the cache invalidation will happen within 4 months when changing templates. But it didn't. I prefer a solution over an explanation. --Herzi Pinki (talk) 11:33, 30 August 2024 (UTC)[reply]
It's a question for WMF.
 ∞∞ Enhancing999 (talk) 11:35, 30 August 2024 (UTC)[reply]
@Herzi Pinki: Working on 50,796 files with COM:AWB applying {{subst:void}} at ~15-30/min (with time off for RL)...   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:31, 30 August 2024 (UTC)[reply]
There isn't just one such category: Special:WantedCategories.
 ∞∞ Enhancing999 (talk) 14:48, 30 August 2024 (UTC)[reply]
@Enhancing999: Can anyone do this with touch.py?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:28, 30 August 2024 (UTC)[reply]
Not sure if this is the solution Herzi Pinki is asking for, as they state it in their question.
 ∞∞ Enhancing999 (talk) 15:39, 30 August 2024 (UTC)[reply]
@Enhancing999: Either is "a bulk operation for all files".   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:45, 30 August 2024 (UTC)[reply]
I can also write a phab-ticket to the database admins, not sure, whether this will help. Jeff G., thanks for your try but even with AWB this will take days for all categories that Enhancing999 mentioned. I will try touch.py. Herzi Pinki (talk) 16:06, 30 August 2024 (UTC)[reply]
I managed to run touch.py (via pwb.py touch), but I'm slow (sleeping 10 sec. between each touch). Will take approx. 14 hours for Category:Files with coordinates missing SDC location of creation (53° N, 4°E). anything that can be done better? --Herzi Pinki (talk) 16:10, 30 August 2024 (UTC)[reply]
ok, pwb.py touch -pt:1 makes it faster. --Herzi Pinki (talk) 16:25, 30 August 2024 (UTC)[reply]
@Enhancing999: All such categories have now been addressed. VFC is faster than AWB for things it can do, but only on files.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:10, 3 September 2024 (UTC)[reply]
@Herzi Pinki: ✓ Done, finally. Along the way, Windows decided to reboot and AWB displayed "stopped" and had to be killed. I finished with VFC, but the 100 limit is painful to get around and it no longer displays a visual indication while it is processing and no longer auto-activates "more" at the bottom.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:10, 1 September 2024 (UTC)[reply]

one touch per second works, even two jobs in parallel (meaning 2 touches / sec). We have about 1390000 entries in categories listed in Special:WantedCategories. Root cause is the change by User:Multichill on 8 May 2024 [8]. Touching all the 1.4 millions files will take 1400000/60/60/24 = ~16.2 days (1 per sec). --Herzi Pinki (talk) 21:49, 30 August 2024 (UTC)[reply]

Tracked in Phabricator
Task T373722
It seems that recurring changes to Module:Coordinates do not trigger the invalidation of cache. But a change in {{Location}} might (as a workaround). Anybody with admin rights who dares to make a nulledit on this template? best --Herzi Pinki (talk) 22:17, 30 August 2024 (UTC)[reply]
@Herzi Pinki: That template is currently transcluded 28,638,450 times. Template Editors are also allowed to edit it, but "edits should be kept to a bare minimum" after discussion on the talk page Template talk:Location.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:08, 31 August 2024 (UTC)[reply]
@Jeff G.: yes I know all that, but if we don't fix problems, because of such performance guidelines, we are doomed. btw, I think something is wrong with the statement of the category, that SDC location is missing. I made a few samples, and all had SDC coordinates. So maybe there is just a flaw in the implementation of these maintenance categories. --Herzi Pinki (talk) 07:27, 31 August 2024 (UTC)[reply]
Did you check that coordinates was in same property (location of creation (P1071)) than tracking cat function expects? Zache (talk) 08:31, 31 August 2024 (UTC)[reply]
No, never heard of location of creation (P1071). What is the difference between the location of creation (of a photo) and the camera location? Ah, it is not just coordinates. So it only makes sense, if this means the location of creation of the depicted object, a property for the vast majority of depicted objects we don't know (think of persons, where they have been created in most cases not even the parents know for sure; a work of art was created in some atelier, but not on the location of final placement). Just another maintenance category that wise men have created and nobody will do the necessary maintenance for. --Herzi Pinki (talk) 08:56, 31 August 2024 (UTC)[reply]
AFaik P1071 is most specific item of place where image has been taken (ie. position of photographer). Ie. it can be administrative area, island, building etc. It is useful expecialy when there is no known coordinates. --Zache (talk) 12:49, 31 August 2024 (UTC)[reply]
@Herzi Pinki: usually it takes a while for cache to pick up, but this is quite extreme. I'll have a bot flush it out. That will be fairly quick.
As for the usefulness: Please assume good faith for the things you haven't heard of before. We're talking about photographs here. Photographs have been taken from some location. See for example File:Grote Kerk an Vleeshal building Harlem.jpg: Here we have coordinates and location of creation (P1071) -> Grote Markt (Q1083850).
In the future this could be used for faceted search: You search for a topic, for example "church", and the search engine will give you options, like location to drill down. In this case by location Europe (Q46) -> Netherlands (Q55) -> North Holland (Q701) -> Haarlem (Q9920)
To break the chicken and the egg problem, I'm adding the location of creation (P1071) based on several sources one being reverse geocoding so that hopefully, we can do a faceted search pilot in the future. Multichill (talk) 11:50, 1 September 2024 (UTC)[reply]
@Multichill: thanks for caring - it seems to me that your quota is much better than mine. Thanks for the explanation, was expecting something like this. As for AGF, I'll try to trust everybody here (without much individual difference in weigth btw.), but if things get contradicting, I'm lost. For me still it is not clear, that location of creation (P1071) (I also trust the property description) is about the photo itself and not the object depicted on the photo. Maybe you can make that clearer in the description of the categories {{Missing SDC location of creation}} mentioned here and maybe we should add something to location of creation (P1071) like most accurate place a photo was taken. May I mention, that openstreetmap nominatim can do this mapping of coordinates to place names out of the box. best --Herzi Pinki (talk) 12:59, 1 September 2024 (UTC)[reply]

mostly done by collective endeavour. --Herzi Pinki (talk) 18:55, 3 September 2024 (UTC)[reply]

Old version of the picture should be a separate file

Smiley.toerist (talk) 08:37, 30 August 2024 (UTC)[reply]

The overwritten version is also a good picture of the same locomotive and place.

overwritten version

@Smiley.toerist: see Commons:History_merging_and_splitting#History_splitting --Herzi Pinki (talk) 09:14, 30 August 2024 (UTC)[reply]
Why bring it to our attention? Both images are uploaded separately, and correctly per COM:OVERWRITE, they are both catted in Category:Midi E 4100 → SNCF BB 4100. The uploader had uploaded both in 2011, but initially had overwritten the other in error, and re-uploaded both in 2011 to correct that. Since then catting has varied, because they have been treated separately, they were never linked, which I just did. So there's nothing to do here.
Meanwhile, I have found an established and prolific uploader who has violated :COM:OVERWRITE., probably 100's, perhaps a 1000 times, unchecked since early 2019. What to do about that? Broichmore (talk) 12:12, 30 August 2024 (UTC)[reply]
File:BB 4162 au dépot de Miramas (BdR) en Septembre 2010.jpg looks more like a glitch. The two versions were uploaded in the same minute and only one appears in the file history.
 ∞∞ Enhancing999 (talk) 12:20, 30 August 2024 (UTC)[reply]
Maybe, but fixed the next day as you say. Broichmore (talk) 12:27, 30 August 2024 (UTC)[reply]
@Smiley.toerist: The images are catted as being in the station, but they are actually in a local depot? Broichmore (talk) 12:36, 30 August 2024 (UTC)[reply]
There is a whole railcomplex in Miramas and probably a local depot. It has an turntable but no building around it. In https://www.openrailwaymap.org/?style=standard&lat=43.581970504642214&lon=4.993975460529327&zoom=18 I see a smaal depot with two tracks.Smiley.toerist (talk) 20:55, 1 September 2024 (UTC)[reply]

August 31

Disambiguating categories

From what I've seen there appears to be two or three main ways that categories are disambiguated at this point. Usually it's done by using brackets or a comma, but I've also seen them disambiguated using other symbols. For instance the Russia symbol for "<" and "<." Having multiple ways of doing it seems to go against the universality principle. Plus at least with commas they aren't super intuitive since plenty of normal names contain commas. Nor are they that easy to see in the first place. "John Malkovich (actor)" makes way more sense and is much easier to see then "John Malkovich, actor", "John Malkovich <<actor>>", or any of the other alternatives I've seen. So at least IMO round brackets should be the de-facto way to name disambiguated categories. Thoughts? Adamant1 (talk) 01:21, 31 August 2024 (UTC)[reply]

Round brackets (parentheses) are the normal way to do this, but U.S. and Canadian place names (and, I suspect, some others) are rather universally written with commas when including the state/province. I think anyone from those countries would find it very odd to see, for example, "Columbus (Ohio)" or "Stratford (Ontario)" rather than "Columbus, Ohio" and "Stratford, Ontario". - Jmabel ! talk 01:54, 31 August 2024 (UTC)[reply]
@Jmabel: That's probably one the few places where a comma is fine, if not expected. There's a lot of categories for streets in Germany its like "X street name, Y location" Which I don't think is a good way to do it. I don't have a problem with a comma being used for something like "city, state" as long as its the norm for similar categories. Its annoying to see a common in cases where the norm is circular brackets, visa versa, or no disambiguating of similar categories to begin with though (Its tangential, but a lot of disambiguation seems to be totally pointless in the first place). --Adamant1 (talk) 02:22, 31 August 2024 (UTC)[reply]
Pretty sure Mexico also shares that North American convention. - Jmabel ! talk 01:57, 31 August 2024 (UTC)[reply]
@Jmabel: What do you think about something like the subcategories for streets in Category:Streets in Lutsk? Would you disambiguate them using a comma, circular brackets, not disambiguate them at all, or just leave them as is with "in Lutsk" at the end of the street names? --Adamant1 (talk) 05:11, 1 September 2024 (UTC)[reply]
I'd certainly want to see them consistent with one another, whatever is chosen. "in Lutsk" seems awkward, but it's also apparently what the most active categorizer here has chosen. I don't much care between comma and parentheses (circular brackets) as long as it's consistent. I'd have no objection to a site-wide standard, but we should at least be consistent within a city. Without a site-wide standard, if you really wanted to work on this for a particular city, I'd make sure to have consensus from the (presumably few) people who most work on images of that city. - Jmabel ! talk 16:18, 1 September 2024 (UTC)[reply]
I changed my mind from ()-notation to comma-notation for Category:Streets in Vienna for two reasons: 1) to make names uniform and 2) acc. to Commons:Language policy category names (except proper names) have to be in English. In English for me does not only mean to translate words, but also to use the structure as it is used in :en:WP. Which is for geographical names (I consider street names as such) "Columbus, Ohio" or "Stratford, Ontario". But uniform name schemes are prior to that, and I try to follow naming schemes already found, sometimes change to the more widely used scheme. best --Herzi Pinki (talk) 13:49, 4 September 2024 (UTC)[reply]

Deletion category update as a step in closing DRs?

I recently had cause to look for all DRs about a given topic and was glad to find our deletion sorting categories. I started to try to add DRs to categories but there was no easy way to choose from a list or quickly cross-reference what options are available, so I made a script which is far from perfect but works well enough for me.

What I'm surprised by are the number of DRs that are closed but still in the /pending subcategory. Why isn't changing /pending to /kept or /deleted a standard part of closing a DR? — Rhododendrites talk |  03:02, 31 August 2024 (UTC)[reply]

It seems like administrators don't change the categories much when they close DRs. So I'll usually do it myself if it's one that I started or was otherwise involved in. Probably their time better spent doing other things anyway and I kind of feel like it's part of the process of completing circle so to speak for whomever opened it. --Adamant1 (talk) 03:32, 31 August 2024 (UTC)[reply]
I presume admins use a script when closing discussions? In which case the script could just be modified. — Rhododendrites talk |  03:42, 31 August 2024 (UTC)[reply]
Oh yeah. I totally didn't think of that but your probably right. --Adamant1 (talk) 05:46, 31 August 2024 (UTC)[reply]
While I believe there is a script available for closing DRs, I doubt that is how the majority are closed. - Jmabel ! talk 17:07, 31 August 2024 (UTC)[reply]
@Jmabel: It's an official gadget, MediaWiki:Gadget-DelReqHandler.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 23:21, 31 August 2024 (UTC)[reply]
@Jeff G.: Yes, I occasionally use it, but it's got its issues. - Jmabel ! talk 23:29, 31 August 2024 (UTC)[reply]
@Jmabel: Then please feel free to discuss them at MediaWiki talk:Gadget-DelReqHandler.js.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 23:39, 31 August 2024 (UTC)[reply]
The main problem is that it puts a bunch of action tags on any file that gets mentioned in a DR and I doubt that can be changed. - Jmabel ! talk 23:57, 31 August 2024 (UTC)[reply]
Wow, that's a really weird way to do it. --Adamant1 (talk) 00:28, 1 September 2024 (UTC)[reply]
@Jmabel: That seems to be a way of weeding out trigger-happy Admins.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 00:35, 1 September 2024 (UTC)[reply]
I guess much of it has to do with the fact that when you're working with the daily DR pages (which are presenting all DRs from a given day), you don't see these categories. You'd have to load the DR as an individual page to see them and change them. Some admins do that, some don't. You can close DRs really fast when working with the daily pages and using DelReqHandler, but the categories stay untouched then. --Rosenzweig τ 12:30, 1 September 2024 (UTC)[reply]
Ohhh that's a good point. Maybe what we need is (a) demonstrated consensus that these sorting categories are indeed worth maintaining, and if so then (b) update deletion nomination scripts/gadgets to incorporate categorization, plus (c) a bot which can automatically update closed DRs... — Rhododendrites talk |  20:59, 1 September 2024 (UTC)[reply]

[SOLVED] Upload via OpenRefine: how to include the "description" for the Information-Template

Hello! Please excuse, if this is the wrong place for this question. I am preparing the upload of ca. 1900 images via OpenRefine, and this is my first ever upload of images on Commons (and use of OpenRefine). See my User:CalRis25 for more about these uploads. I have read quite a bit on Commons and been working through the course OpenRefine for Wikimedia Commons: the basics (WMF_GLAM001) and have solved (or so I think) most problems. However, I am still somewhat at a loss as to how to supply the description for the Template:Information. According to Commons:File captions this description is not part of the structured data. But how can I tell OpenRefine (or Commons) to use a certain column of the CSV-file, which contains the respective text, as the description for the Information-template? Can anyone help me? Thank you in advance, CalRis25 (talk) 10:06, 31 August 2024 (UTC).[reply]

  1. you should make test runs of small batches (10-30) to check if there will be errors/problems.
  2. you might need to consider applying for a bot account.
  3. Commons:OpenRefine/Uploading files with OpenRefine#Use simple (minimal) wikitext!?

    if what you mean is you have prepared most or all data into com:sdc except the description, you could just do this {{Information|description={{en|1=...}}}} ?

RZuo (talk) 10:22, 31 August 2024 (UTC)[reply]
Uploading 1900 files is nothing that requires a bot account. GPSLeo (talk) 10:34, 31 August 2024 (UTC)[reply]
Thank you for the quick answer! I am going to make a test-run with only two images, once I got this problem solved. I actually thought about including the description in the Wikitext. However, according to this Commons-page this is actively discouraged. Or do I misunderstand this page? I use a Python-script to generate the CSV-file, so changing things is not a big problem. Is there really no way to tell OpenRefine to use the content of one of the columns as the description for the Information-template? Or do you mean with {{Information|description={{en|1=...}}}} that there should be a column (separate from that with the simple wikitext) containing that bit of information? CalRis25 (talk) 10:48, 31 August 2024 (UTC)[reply]
  • I made a test-upload of 1 image (see its page). The file was uploaded, but none (!) of the data I supplied (including various structured data items reconciled with Wikidata) was added. And I still don't know how to supply the Commons-description of the Information-template in OpenRefine. CalRis25 (talk) 09:07, 1 September 2024 (UTC)[reply]
  • After quite a few trials I was able to create several test images. Including the description was only possible by directly editing the Wikitext. I am going to head over to the Help Desk and ask someone to have a look at the page of the test file. CalRis25 (talk) 17:56, 1 September 2024 (UTC)[reply]

September 01

Hello, I'm sorry. I believe this image is not under permission and I'm just now realizing it. Mário NET (talk) 02:38, 1 September 2024 (UTC)[reply]

@Mário NET: it looks like that file page is a mess in terms of what it states, but if the image is from Adalbert Seitz (died 1938, which means PD in Germany) and was published in 1927 (which means PD in the U.S.) it should just be a matter of cleaning up the claims on the file page. And if it does come originally from the 1845 work mentioned there, then the case is even clearer. What has you concerned? - Jmabel ! talk 02:52, 1 September 2024 (UTC)[reply]
I thought it would say "free copyright" in "Show Info" and it said "Copyright & Usage, Due Diligence"; so I couldn't interpret what it was. 03:18, 1 September 2024 (UTC) Mário NET (talk) 03:18, 1 September 2024 (UTC)[reply]
@Mário NET: "free copyright" makes no sense at all. Perhaps you are thinking "copyright-free" (meaning that there is no copyright)?
I'll try to fix the page myself, because I'm pretty sure your recent edit (which I reverted) only made this worse. - Jmabel ! talk 16:23, 1 September 2024 (UTC)[reply]
Please correct me if I am wrong, but, it's not the case for public domain works such as the one here, but, for CC-licensed works, I believe that there is copyright in place, and there is a free license one (the requirement to cite the original author, or to redistribute the work under the same license, in the case of CC-BY-SA, is due to copyright law: the work's author has copyright ownership, and licenses the work to others under a CC license). So in some cases, not for public domain works such as this, but "free copyright" could make sense as a phrase. MGeog2022 (talk) 09:15, 2 September 2024 (UTC)[reply]
@MGeog2022: I couldn't fully follow some of your English, but if I follow you correctly you are describing "copyrighted free-licensed work", and I stand by my original statement. If I've misunderstood you, feel free to write in Spanish, which I read without difficulty. - Jmabel ! talk 22:25, 2 September 2024 (UTC)[reply]
@Jmabel, it's probably because how I chained one sentence after another, perhaps I did it in a too Spanish-like way. Yes, I'm talking about copyrighted free-licensed works, and, so, you're completely right, "free copyright" perhaps may never make sense, since there is this another way to say it. Sorry, but, some time away, I saw a misunderstanding in a Wikipedia talk page, where someone seemed to say that the mere presence of a copyright tag implied that a work could not be freely licensed, and I think it's a dangerous error, since it may lead to the removal of legitimate content, so I wanted to draw attention to it (not so much because you thought so, which seemed very unlikely, but because of others who might read it). MGeog2022 (talk) 09:23, 3 September 2024 (UTC)[reply]
Wait, I'm confused, too. Where did the mention of an 1845 work come from? What is the source for that information? - Jmabel ! talk 16:35, 1 September 2024 (UTC)[reply]
This work is not from 1845, what happens is that I used a text from another image to construct this one and I didn't realize that the "1845" from the previous text had remained, I will correct that. Mário NET (talk) 01:55, 2 September 2024 (UTC)[reply]

Native American fishing rights

We don't seem to have a category for Native American fishing rights (nor hunting rights, but offhand I don't have any content for that). I'm not sure how to bes get that into our category hierarchy: it's a matter of tribal treaty rights, not civil rights. We have at least File:Helix, v.4, no.5, Aug. 29, 1968 - DPLA - 841a1a68f4295fee3a912baf0c87caaa (page 9).jpg, File:Helix, v.4, no.6, Aug. 29, 1968 - DPLA - 73a8fb15a58855b090d500dba021b984 (page 4).jpg, File:Helix, v.4, no.7, Sep. 12, 1968 - DPLA - feeee1d59fc70ba359e15965679dafbf (page 6).jpg, and Category:Billy Frank Jr. that would belong there. I suspect there are a fair number of other files and possibly categories. - Jmabel ! talk 02:57, 1 September 2024 (UTC)[reply]

Speedy because "File has no source" but what they are saying is "I want to see a url" instead of what is listed

@Winmyint998: See: Special:Contributions/Winmyint998 where they are sending images to speedy because the "File has no source" but what they are saying is "the source listed is inadequate". Should these images be going to speedy? A few years ago there was a problem with another editor using Speedy with: "File has no license" but what they were really saying was "I don't think this image has the correct license". Should these be going to speedy for auto-deletion and no further research, or through the regular process where the community does more research if needed? Should the normal deletion nomination process be so easy to circumvent? Should the "Speedy" be removed? RAN (talk) 07:39, 1 September 2024 (UTC)[reply]

Yes, this is an inappropriate use of the speedy deletion tag and they should be converted to regular deletion requests. Speedy deletions should only be used for clear and unamibiguous copyright violations. Checking a few files that they tagged, despite lacking in sourcing the files appear to be old enough for their copyright to have lapsed in Myanmar. ReneeWrites (talk) 07:57, 1 September 2024 (UTC)[reply]
Agree with RAN and ReneeWrites, but things are certainly not helped when (for example) [[User:History of the Burmese}} says source is {{Own work}}, date is three days before the upload, and the license is {{PD-Myanmar}}. Presumably it's the source and date that are wrong here rather than the license, but the source and date are not even plausible. - Jmabel ! talk 16:57, 1 September 2024 (UTC)[reply]
  • If we deleted every noobie upload that used the upload date as the creation date for an historical image, we would not have many images. The new upload form is supposed to reduce those kind of errors. One of the risks of a nominator using speedy, I believe, is that you can just challenge "speedy" by just removing the tag and not forcing it to a standard deletion nomination. --RAN (talk) 00:38, 2 September 2024 (UTC)[reply]

Question (in English) about categories in Chinese

Please see Commons:Village_pump/zh#Commons:Report_Special:UncategorizedCategories_in_zh.

I posted it there due to the (assumed) language of the categories, but it's unclear if that Village pump is actually read.
 ∞∞ Enhancing999 (talk) 11:08, 1 September 2024 (UTC)[reply]

looks like a perennial problem for chinese books.
you can dump this code on all of them whenever such categories appear in future.
{{Category for book|zh}}
[[Category:Chinese-language books by title]] RZuo (talk) 16:54, 1 September 2024 (UTC)[reply]
Thanks. Will do. Ideally the categories (and files) would have {{Book}} or at least an infobox.
 ∞∞ Enhancing999 (talk) 17:24, 1 September 2024 (UTC)[reply]

adding wdib without knowledge of the books only adds to maintenance backlog unnecessarily.--RZuo (talk) 23:29, 1 September 2024 (UTC)[reply]

Abusefilter to prevent uncategorised pages？

are all pages in main and category namespaces supposed to be categorised? if so then perhaps an abusefilter can be created to prevent creation of such pages without any "Category" or "{{" in source? (pages are categorised either directly or by transcluding a template.) RZuo (talk) 11:12, 1 September 2024 (UTC)[reply]

The ones on Commons:Report UncategorizedCategories with infobox all have "{{".
To update the list I have to purge recent creations to ensure those connected to Wikidata, but without edits since don't end up there.
For files, everything just ends up in Category:All_media_needing_categories_as_of_2024. Do users still get notified when they don't categorize?
 ∞∞ Enhancing999 (talk) 11:38, 1 September 2024 (UTC)[reply]

Commons Gazette 2024-09

Volunteer staff changes

In August 2024, 1 sysop was removed. Currently, there are 183 sysops.

We thank him for his service.

Other news

Edited by RZuo (talk).

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

--RZuo (talk) 23:04, 1 September 2024 (UTC)[reply]

I suggest that the Commons community should take action in the event that Cat-a-lot is slowed down (effectively to the rate of 1 edit per second). I don't want to disagree with SRE-team's conclusions, but this unilateral change to the "coolest tool" has affected many users' workflows (including mine). — Draceane talkcontrib. 20:11, 3 September 2024 (UTC)[reply]
Maybe you can propose a better implementation ? Or sprinkle some pixie dust ? As long as it doesn't cause all of Wikimedia to got down multiple times a week, any of it is welcome. —TheDJ (talk • contribs) 21:21, 3 September 2024 (UTC)[reply]
I think the bug was identified two months ago. Something in relation to a change WMF made to Special:Search.
 ∞∞ Enhancing999 (talk) 21:28, 3 September 2024 (UTC)[reply]

September 02

How do I use autowikibrowser?

I want to start using AWB since I upload large amounts of files and want to make mass edits to them. How can I use it? I know it has a permission requirement, so how hard is it to get it? Immanuelle ❤️💚💙 (please tag me) 10:44, 2 September 2024 (UTC)[reply]

@Immanuelle: See Commons:AutoWikiBrowser —Justin (koavf)❤T☮C☺M☯ 10:47, 2 September 2024 (UTC)[reply]
Hi, Did you try Visual File Change? Yann (talk) 10:47, 2 September 2024 (UTC)[reply]
@Yann thank you that works great Immanuelle ❤️💚💙 (please tag me) 11:22, 3 September 2024 (UTC)[reply]
Let me also endorse VFC. I use it pretty heavily; I've used AWB now and then, but have found VFC generally easier for most purposes. - Jmabel ! talk 22:27, 2 September 2024 (UTC)[reply]
@Jmabel how do I make it appear and where should it be appearing? I started it but I cannot find it and I think I either didn't clear my cache or didn't properly activate it. Immanuelle ❤️💚💙 (please tag me) 12:28, 3 September 2024 (UTC)[reply]
@Immanuelle: It should appear as "Perform batch task" with the rest of your tools. See Help:VisualFileChange.js#Step 0: How to Install, including the "If you do not have the autopatrolled right: add" bit.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:48, 3 September 2024 (UTC)[reply]
@Jeff G. that was it. I was confused since I thought autopatrolled was something you got automatically. Thank you. Immanuelle ❤️💚💙 (please tag me) 16:49, 3 September 2024 (UTC)[reply]
@Immanuelle: Right, you got autoconfirmed automatically four days after you registered December 5, 2021 at 22:44:14 (UTC). You're welcome.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:55, 4 September 2024 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:04, 4 September 2024 (UTC)

Please help verify the authorization license of the video files uploaded from the bilibili.com website.

Unlike YouTube and Flickr, bilibili.com does not have a Creative Commons license setting, so users need to manually mark similar licenses. A bilibili.com user contacted me and asked me to help him upload some video files to WikiCommons under CC-BY-4.0 license. The files are listed below, and I hope someone can check the license.

— Preceding unsigned comment added by Fumikas Sagisavas (talk • contribs)

@Fumikas Sagisavas: Where on bilibili.com can we verify that this person has granted this license for these files? - Jmabel ! talk 22:31, 2 September 2024 (UTC)[reply]
For example, this video file is File:Freshippo torch meat skewers.webm, and the original video file is marked "本视频按照署名 4.0 协议国际版进行授权（CC-BY-4.0）" in the summary. Fumikas Sagisavas (talk) 22:40, 2 September 2024 (UTC)[reply]
✓ Done. Jmabel ! talk 04:07, 3 September 2024 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jmabel ! talk 04:07, 3 September 2024 (UTC)

Announcing the Universal Code of Conduct Coordinating Committee

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

Hello all,

The scrutineers have finished reviewing the vote and the Elections Committee have certified the results for the Universal Code of Conduct Coordinating Committee (U4C) special election.

I am pleased to announce the following individual as regional members of the U4C, who will fulfill a term until 15 June 2026:

  • North America (USA and Canada)
    • Ajraddatz

The following seats were not filled during this special election:

  • Latin America and Caribbean
  • Central and East Europe (CEE)
  • Sub-Saharan Africa
  • South Asia
  • The four remaining Community-At-Large seats

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

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

On behalf of the U4C and the Elections Committee,

RamzyM (WMF) 14:05, 2 September 2024 (UTC)[reply]

Help us learn about On-Wiki Collaborations

The Campaigns team at the Wikimedia Foundation is exploring how to expand it's work on campaigns, to support other kinds of collaboration. We are interested in learning from diverse editors that have experience joining and working on WikiProjects, Campaigns, and other kinds of on-wiki collaboration. We need your help:

Whatever input you bring to the two spaces will help us make better decisions about next steps beyond the current tools we support. Astinson (WMF) (talk) 18:53, 2 September 2024 (UTC)[reply]

Japanese category

A Japanese-speaking editor is need to describe and categorise Category:Nagoya Location Navi, please.

As an aside, do we have a forum to find editors with certain language skills; or cultural understanding? On Wikipedia I would use a wikiproject, or WP:Embassy. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:32, 2 September 2024 (UTC)[reply]

Could you use the Wikipedia embassy for this as well? That's what I would do, even if it's not 100% the right avenue. There are two editors listed for the Japanese language there, and BorgQueen is highly active. ReneeWrites (talk) 21:19, 2 September 2024 (UTC)[reply]
Yes, but my question was whether we have a local forum. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:35, 3 September 2024 (UTC)[reply]
@Pigsonthewing I described it. Immanuelle ❤️💚💙 (please tag me) 13:29, 3 September 2024 (UTC)[reply]

September 03

Have your say: Vote for the 2024 Board of Trustees!

Hello all,

The voting period for the 2024 Board of Trustees election is now open. There are twelve (12) candidates running for four (4) seats on the Board.

Learn more about the candidates by reading their statements and their answers to community questions.

When you are ready, go to the SecurePoll voting page to vote. The vote is open from September 3rd at 00:00 UTC to September 17th at 23:59 UTC.

To check your voter eligibility, please visit the voter eligibility page.

Best regards,

The Elections Committee and Board Selection Working Group

MediaWiki message delivery (talk) 12:13, 3 September 2024 (UTC)[reply]

In case you were wondering:

 ∞∞ Enhancing999 (talk) 13:02, 3 September 2024 (UTC)[reply]

Are amulets toys?

I am having some of the files I uploaded being proposed for deletion as toys, to my knowledge they are amulets, not toys, considered to have religious significance. Does that change things? Commons:Deletion requests/File:Okimono omikuji.jpg This overall applies to the entire category Category:Doubutsu mikuji Immanuelle ❤️💚💙 (please tag me) 13:15, 3 September 2024 (UTC)[reply]

They are presumably not "toys", but uhey are certainly copyrightable in the U.S. I can't speak for Japan. - Jmabel ! talk 18:06, 3 September 2024 (UTC)[reply]

I have many photos of a ship, but I do not know which one it is

In this category Category:Kyushu Yusen there are six operational ships. Of these ships, two are of one class, and 4 are of another class. I have many photos taken of and on each class, but I am not sure how to categorize them. Immanuelle ❤️💚💙 (please tag me) 13:18, 3 September 2024 (UTC)[reply]

You could add them in the categories for classes and Category:Unidentified ships.
 ∞∞ Enhancing999 (talk) 13:32, 3 September 2024 (UTC)[reply]
And it is certainly OK to create a category for each class. - Jmabel ! talk 18:07, 3 September 2024 (UTC)[reply]

Hi there! A colleague of mine has been working for many years on the topic of image searching. His focus is not just on finding images that are tagged with keywords, but also finding similar images for various definitions of similar. He managed to obtain 6 million images from Commons to demonstrate his technology, it is freely available at WikiView. He has tried to find someone at Commons who knows if an API for Commons exists and if it does, if it is possible to just pull new pictures and not have to pull a dump at regular intervals. It would be cool to offer this visual search (quite a different way of searching, try it!) from the home page and also to have it stay up-to-date. If you are such a person, please contact me in-wiki and I'll put you in touch with my colleague. Thanks! --WiseWoman (talk) 18:43, 3 September 2024 (UTC)[reply]

"He managed to obtain 6 million images" ... sigh. I trust they didn't clear this with anyone ? —TheDJ (talk • contribs) 21:18, 3 September 2024 (UTC)[reply]
I was thinking about doing a similar thing to train an AI image generator but who knows how it work with all the different kinds of licenses on here. At least in that case the generated images would be different from the originals. It still seems questionable though to just take millions of images with different licenses and use them in a single product in mass though. I don't there's any way to follows the licensing terms for every image. Especially an in instance like this one. Let alone with an AI image generator. --Adamant1 (talk) 02:07, 4 September 2024 (UTC)[reply]
I wasn't part of the project, but they did speak to someone. The problem is, that the people change and this is so difficult for people not in the Wikiworld to sort out who they have to speak with. But there is a link back to Commons when an image is found the license is clearly given in Wikiview. I believe they only used images that were usable according to the license, and that was the problem, being able to obtain new pictures but only those ones with a fitting license. The WikiWorld seems so difficult to people not active here, often because the tone is a bit rough. --WiseWoman (talk) 11:42, 4 September 2024 (UTC)[reply]
Template:WiseWoman After I commented I noticed that they have a way to sort the images by license and that there's links back to the images on Commons. Both of which helps. I can understand why this would be difficult for people who aren't active in the project already. It can be a little rough and the sheer amount of different licenses with multiple variations per license based on the personal preferences of uploaders really doesn't help. I'd love to see them at least get rid personalized licensing terms. If not just the different defaults down to 1 or 2. There's like what, 7 different versions of the Creative Commons license on here at this point though? The whole things totally ridiculous. --Adamant1 (talk) 20:41, 4 September 2024 (UTC)[reply]
Sounds amazing! Have a look at m:Community Wishlist/Wishes/Search Wikipedia with image or sketch search and maybe also comment on the talk page there. It didn't work so well with search terms but one can use WMC search for that anyway and it seems like the focus there is searching by image. I would suggest the asap it also shows the WMC categories by number of images in the results they contain, this way one can find relevant categories that contain more images. Also see my proposal about data dumps (and the link at the top there) which may make it possible to just pull new pictures which would also be great to improve WMC performance and reduce server load. I don't think it will be linked on the main page if it's not searching across all WMC images and is an external site but probably it could be linked at some other page not far from it – I don't know of use-cases where one would want to search by image and not via search terms or by browsing. Prototyperspective (talk) 22:21, 3 September 2024 (UTC)[reply]
They also have a tool that kind of sort of works with sketching (but used a different image collection for this one). It would be so important for the researchers in this area to speak with people at Wikimedia to sort out how to move forward on this. --WiseWoman (talk) 11:42, 4 September 2024 (UTC)[reply]

September 04

CfD for categories of nonexistent WikiProjects

Hi. I got in a little tiff with a another user earlier because I nominated some categories they created for nonexistent WikiProjects for speedy deletion. I don't really feel like relitigating it here. Except to draw people's attention to Commons:Categories for discussion/2024/09/Category:WikiProject Iran by city. Personally, I feel like it clearly violates the guidelines and consensus to create categories as part of a personal pet project for things that clearly don't exist. Apparently the user who created the categories thinks it's totally fine though. So I started a CfD to see what other people think about it. The categories seem totally pointless and unhelpful to me, but who knows. Maybe I'm missing something or there's a valid reason to keep them that I'm just not aware of. Adamant1 (talk) 08:43, 4 September 2024 (UTC)[reply]

To repeat it for fourth (!) time: these categories are not intended for existing WikiProjects, but for separating huge WikiProject Iran by particular city, although there are some individual projects like WikiProject Tehran on Persian Wiki. They serve as maintenance categories and exist for years. The issue here is Adamant1 yesterday planned to delete everything, without any proposal or discussion, making an utter mess with hundreds of related categories, so I reverted him. --Orijentolog (talk) 09:04, 4 September 2024 (UTC)[reply]
The CfD is a better place to discuss the particulars. I will point out though that Commons:Categories states "we should not classify items which are related to different subjects in the same category. There should be one category per topic; multi-subject categories should be avoided. The category name should be unambiguous and not homonymous." Maybe it's just me, but I really don't see how it isn't ambagious to have a category called "WikiProject Jahrom" when there's WikiProject Jahrom and it's just a maintenance category. I certainly thought it was a category for a real WikiProject at first. I certainly didn't know it was maintenance category for WikiProject Iran until you told me. So there's clearly some ambiguity here about the purpose of the categories and why exactly they exist. Just because it's clear to you as the person who created them that doesn't mean other people will understand it and they should. Otherwise the categories should be deleted. Period. There's absolutely zero justification what-so-ever to have categories that only make sense to the person who created them. --Adamant1 (talk) 09:13, 4 September 2024 (UTC)[reply]
WikiProject Jahrom serves as a part of the WikiProject Iran and contains things related to the city of Jahrom. If it doesn't make sense to you, that's not my problem. --Orijentolog (talk) 09:27, 4 September 2024 (UTC)[reply]
Then the category should be called something like "Category:WikiProject Iran in Jahrom" or "Category:WikiProject Iran (Jahrom)"; if you make categories that do not conform to our naming standards, that will very quickly become "your problem"". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:14, 4 September 2024 (UTC)[reply]
@Pigsonthewing: don't think I'm scared Andy, making 1,000 or 10,000 edits to correct something ain't an issue for me, and I'm a collaborative person. Only the messiness and lack of unification scares me. As I said to Adamant1 today, if there's a consensus to rename everything, I'll do it personally. I prefer keeping the status quo (yes, it's laziness!), but I would accept your proposal if others agree. Generally it's fine and I have only minor issues with it. Another thing, I don't see that strict naming standards apply to maintenance categories, there are a lot of uneven, non-English and even illiterate ones around. --Orijentolog (talk) 17:37, 4 September 2024 (UTC)[reply]
I don't think you're scared at all. Why on earth would you say that? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:58, 4 September 2024 (UTC)[reply]
@Pigsonthewing: please don't take me literally, it was a jesting message that I'm always ready to massively correct my own errors. --Orijentolog (talk) 18:12, 4 September 2024 (UTC)[reply]
There are a lot of uneven, non-English and even illiterate ones around. The guideline for naming categories was improved last year (after an extremely long CfD that had more then enough support at the time BTW). So there's naturally going to be some uneven, illiterate categories at this point. It takes time to cleanup this stuff up once a guideline is changed and that's not helped or made quicker by the needless edit waring and discussion over it on your end.
More to the point, something like "Category:WikiProject Iran in Jahrom" or "Category:WikiProject Iran (Jahrom)" would be better. Although I still think the categories would be mostly pointless and not make sense. As a category like "Category:WikiProject Iran in Jahrom" still insinuates that there's a WikiProject in Jahrom or that Wikiproject Iran has a satellite group when neither one is true. If someone creates a category called "X business in Y location" then that business should have some dealings in that location or the category is fundamentally wrong. --Adamant1 (talk) 19:16, 4 September 2024 (UTC)[reply]

Categories which should only contain media of a specific type

what have i just found 🧐

Category:Categories which should only contain media of a specific type. RZuo (talk) 11:37, 4 September 2024 (UTC)[reply]

Image Annotator not working

Hi, is there a problem with ImageAnnotator ?--JotaCartas (talk) 16:05, 4 September 2024 (UTC)[reply]

OK, solved, I had "ImageAnnotator" disabled in Preferences-Gadgets, thanks and sorry for trouble JotaCartas (talk) 16:43, 4 September 2024 (UTC)[reply]

September 05

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