Commons:Village pump

Shortcut: COM:VP

• Community portal
  • introduction
• Help desk
• Village pump
  • copyright
  • proposals
  • technical
• Administrators' noticeboard
  • vandalism
  • user problems
  • blocks and protections

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓

COMMONS DISCUSSION PAGES (index) Commons Help desk Village pump (general discussion) Copyright Proposals Technical Graphics and photography discussion Photography critiques Image improvement Illustration workshop Map workshop Photography workshop Video and sound workshop Categories for discussion Undeletion requests Deletion requests Volunteer Response Team/Noticeboard Translators' noticeboard Work requests for bots Contact administrators Vandalism User problems (Dispute resolution) Blocks and protections Bureaucrats' noticeboard CheckUser requests Oversight requests Telegram IRC webchat Commons mailing list (archive) Commons' bugs on Phabricator 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/07. Please note: 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. Have you read our FAQ? For changing the name of a file, see Commons:File renaming. 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). 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: Please do not make deletion requests here: use the relevant process for it instead. For technical support and graphics talks (PNG, SVG, GIF, etc.), please post on the Graphics village pump. To ask for image improvement, see: Graphic Lab/Photography workshop for photographs. Graphic Lab/Map workshop for maps. Graphic Lab/Illustration workshop for other illustrations. To ask for video or audio improvement, see Commons:Graphic Lab/Video and sound workshop. For translation requests, please post at Commons:Requests for translation. For media requests, please post at Commons:File requests. Search archives:     Start a new discussion

Legend
In the last hour
In the last day
In the last week
In the last month
More than one month
Manual settings
When exceptions occur, please check the setting first.

Women at the well, India, early 20th century. [add]

Centralized discussion See also: Village pump/Proposals   ■ Archive Commons:Requests for comment/Hosting of free fonts in Commons (18 July 2024) How do we organize categories by date (14 May 2024) Should PD-CQ Roll Call be used for recent images? (5 January 2024) Technical needs survey (17 December 2023) When does PDART apply to textile works? (15 November 2023) Does this image contain "love hearts"? (17 August 2023) Overhaul of categories by period (5 December 2022) Version of Saudi flag to use (11 July 2022) Concern regarding revocability of KOGL licenses (22 December 2021) Should deleting content from your own talk page be forbidden? (11 November 2021) Revise the COM:FOP Sweden section (1 February 2021) Change technical name of LRs to license-reviewer from image-reviewer(2 November 2023) Template: View   ■ Discuss    ■ Edit   ■ Watch

	SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days.

July 05

German currency files without machine-readable license

Category:Files with no license using PD-GermanGov-currency has 3,409 files which reside in Category:Files with no machine-readable license due to the fact that they use {{PD-GermanGov-currency}} ex-license which was decommissioned some years ago. Some previous discussions:

• Commons:Village_pump/Copyright/Archive/2012/07#German_currency (2012)
• Commons:Deletion requests/Template:PD-GermanGov-currency (from 2013)
• COM:CUR#Germany

Those files were nominated for deletion in 2013, but saved because it was determined that due "the response from the German government, which is now an OTRS ticket, it would appear that the hosting of these files is in line with Commons' policies." That is great, news but the files still have to have some valid license. Can some German speakers or people understanding nuances of German law help us determine if we need to create some new license templates, resurrect {{PD-GermanGov-currency}}, or delete those files? Jarekt (talk) 03:45, 5 July 2024 (UTC)

Per COM:CUR#Germany, German currency units are "Not OK except for Deutsche Mark bank notes". They can still be ok though if they're some kind of PD-old or PD-ineligible. The Deutsche Mark bank notes would probably need some new specialised license tag. The others will need to be examined one by one if they're ok for PD-old or PD-ineligible reasons, else they will need to be nominated for deletion. This is an ongoing process, just like the one concerning German stamps. I've looked at files showing German currency every now and then and either nominated them for deletion (Category:Currency related deletion requests) or replaced the PD-GermanGov-currency tag with the proper license tags. --Rosenzweig τ 07:46, 5 July 2024 (UTC)

@Rosenzweig: That is a great work you are doing in Category:German currency-related deletion requests/deleted, and a bit sad, as nobody wants to delete good files. The issue is that last time we looked at this in 2013, people were debating about 500 files in Category:PD-GermanGov-currency but 11 years latter we have 3697 files in the same category, so it seems like we gain German currency files with no license much faster than we loose them. Maybe we can start with new PD template for Deutsche Mark bank notes. What would be the rationale behind it? --Jarekt (talk) 12:56, 5 July 2024 (UTC)

I've also removed the deprecated tag from quite a few and added proper PD license tags, so it's not just deletions. The problem is that the PD-GermanGov-currency tag wasn't really properly deprecated until November 2023, so uploaders kept using it and adding files. The DM bank note conditions seem to be in VRT ticket:2012081410006029, someone would have to look at that. Though reading through Commons:Deletion requests/Template:PD-GermanGov-currency I'm a bit skeptical if they would be enough for today's Wikimedia Commons. --Rosenzweig τ 13:55, 5 July 2024 (UTC)

@Rosenzweig: , According to Krd, the ticket:2012081410006029 contains an e-mail from the German Federal Bank stating:

• They cannot answer if DM notes are PDGov ("Amtliches Werk"). This has to be decided by court if required, but they are not aware of any precedent. They do not object the use of the images if they are unmodified and used in good faith.
• They don't have any business in Euro, GDR currency or Reichmark and refer to the department of finance, or the KFW regarding GDR.

That does not seem like a good basis for PD template. So we would have to assume that all the files in Category:Files with no license using PD-GermanGov-currency are copyrighted unless we can prove otherwise. Is PD-old-70 our best option or are there some other exceptions which can be used? --Jarekt (talk) 13:30, 8 July 2024 (UTC)

I suspected it might be something like that, sadly.

We might be able to use {{PD-Germany-§134-KUG}} for some files. That is a very tricky template with several requirements:

• Can only be used for works published for the first time before 1966.
• Those works must be at least 70 years old, so as of 2024, only works before 1954 are eligible. Next year, works from 1954 will become eligible, etc.
• A personal author/artist MUST NOT be named on/in the work. Which should be usually the case with bank notes (not always with 1920s emergency money though), but coins might contain initials of the designer, which is enough for them to be named.
• A corporate entity of a specific kind (a legal entity under public law, de:Körperschaft des öffentlichen Rechts (Deutschland)) MUST be named on the work. The German Federal Bank, the German state itself or one of its subdivisions would fulfil this criterion.

That would need to be examined and decided on a case by case basis. For any works past 1965, we could not use it.

And, per Commons:Licensing, we also would have to consider US copyright (the URAA), which would mean only works which are at least 95 years old are ok. Unless we can find some provision in US law that (foreign) currency units are generally in the PD, which I'm not aware of right now. ---Rosenzweig τ 13:54, 8 July 2024 (UTC)

@Rosenzweig: , That would also mean that coins and banknotes published after 1953 can not use {{PD-old-70}}, {{PD-anon-70-EU}} or {{PD-Germany-§134-KUG}}. Those can be isolated and proposed for deletion. As for US laws, I have not seen any deletions of works in PD in home country but not in the US in last decade or so, so it is less of a priority, but it would not hurt to add {{PD-US-expired}} to currency from before 1929. Another possible approach would be to rewrite {{PD-GermanGov-currency}} as a "previously considered PD" but now no known restrictions license tag before nominating for deletion. Those files do not have known restrictions and seem no worse than other files with no known restrictions license tags. --Jarekt (talk) 16:50, 8 July 2024 (UTC)

@Jarekt: I disagree about US copyright, COM:Licensing is an official policy here at Wikimedia Commons, and files are still deleted because they're not yet in the public domain in the US. If you doubt that, just take a look at current deletion requests. So we should stick to the official policy. The German wikipedia only applies German/Austrian/Swiss copyright law, so some files could perhaps be reuploaded there on demand.

As for a "No known restrictions" license tag, are there really no restrictions? The Federal Bank more or less declares that they won't interfere (similarly here), but is that enough and free enough for a license tag? --Rosenzweig τ 17:35, 9 July 2024 (UTC)

I've looked at the category over the last few days, and it seems that a very large chunk of the files are Notgeld (emergency money) banknotes from 1923 or earlier, uploaded by a handful of users over the last five years or so (which would at least partially explain the increase in the number of files over 11 years). We will be able to keep the majority of those, either with PD-Germany-§134-KUG or because their (named) artists can be identified and died over 70 years ago. Some will have to be deleted though until they can be gradually restored over the next 25 years or so. But sorting all that out will take time. Regarding the other files (which are not Notgeld), most of the older coins and bills from the 1920s and earlier can likely be kept as well. Anything after that will probably have to be deleted and can then also be gradually restored, though very new coins and bills won't be in the PD for many many decades. --Rosenzweig τ 11:43, 14 July 2024 (UTC)

@Rosenzweig: , I did a few things to push things along:

• Created Commons:Deletion requests/German currency after 1953 with files using {{PD-GermanGov-currency}} showing currency published after 1953.
• Added {{PD-US-expired}} to currency from before 1929. That tag is not a substitute for required copyright tag which is valid in Germany, but it keeps files out of Category:Files with no machine-readable license so there is more time to sort out the copyrights of the individual files.
• I removed the files from above 2 groups from Category:Files with no license using PD-GermanGov-currency which shrunk from 3,409 files to 57 files. Files in that category should be in Category:Files with no machine-readable license, have {{PD-GermanGov-currency}} template, and are not nominated for deletion. Some of them are from 1929-1953 years, and some from undetermined time.

--Jarekt (talk) 23:52, 19 July 2024 (UTC)

July 06

POTY (Picture of the Year) competition needs help!

POTY desperately needs new volunteers who can do the things required to run the competition. With the current state of the committee, it is likely that there will be no POTY this year, as the main member who ran scripts for the competition has burned-out from doing wikipedia tasks and isn't up for it. Others on the committee are also missing in action.

Check out the discussion here. Shawnqual (talk) 04:46, 6 July 2024 (UTC)

In the past few months there was a conversation on Commons with someone from the WMF about WMF prioritization of Wikipedias vs Commons this year. Does anyone remember who that is, could they be pinged to make them aware of this issue? I recall part of that conversation was on how Commons is not particularly focused on disseminating and sharing its content - POTY is probably the most visible initiative for Commons to share its top quality images, including outside Wikimedia, and widely engage with Wikimedia contributors across all projects (are there any stats on how many people engage with POTY, and from which wikis?). I'm sure resources for 2024 are already prioritized but visibility could help for 2025. cc @Rhododendrites who I believe was part of that conversation. - Consigned (talk) 10:11, 6 July 2024 (UTC)

This has now come up in several places. The conversation you're referring to is probably this one. There's also some background on the POTY talk page, and on Jimbo's enwp page. — Rhododendrites ^talk |  11:35, 6 July 2024 (UTC)

I think we have a problem if the commons community cannot run a photo competition without WMF's help (Or the help of people who have done it in the past. Helping out once should not imply you are signing up to help every year for the rest of your life). There are aspects of the site's operation that fall on the shoulders of WMF, but a photo competition is surely not one of them. Bawolff (talk) 07:48, 12 July 2024 (UTC)

Please someone save POTY ! This is a very important matter. The POTY contest has been completed successfully every year since 2006 and we can not let it die ! Any help is welcome. -- Giles Laurent (talk) 09:18, 8 July 2024 (UTC)

Seems unsolved (removed solved template). I don't have much else to add than that but I think it would be best to build things so that POTY doesn't require much time or effort to run each year. Just use the same templates, designs, scripts, bots, etc like the year before. --Prototyperspective (talk) 10:48, 19 July 2024 (UTC)

Problem is that it seems like almost no one knows how to simply run the scripts... Giles Laurent (talk) 18:01, 19 July 2024 (UTC)

July 15

Works of art of men smoking (activity)

I've just noticed an item, moved from Category:Smoking men in art to Category:Works of art of men smoking (activity). That just rolls of the tongue, its so intuitive (sic). I thought that brevity was supposed to be the way to go. That what was important, was, that titles be consistent, brief getting to the point quickly, even be elegant. Works of art of men smoking (activity) is the exact opposite of that.

As an aside, what was wrong with just Smoking cigarettes, which is how a commercial endeavour would probably do it. Only humans, of all the animals, are stupid enough to smoke.

Another cat recently moved, from Category:Walking men]] to Category:Men walking. Somehow, I got used to using titles that led with the verb, now, not the case. It has to be the noun.

Why can't there be both, is that such a deal breaker? Broichmore (talk) 16:16, 15 July 2024 (UTC)

See also Commons:Categories for discussion/2024/07/Category:Works of art of women smoking (activity).

 Agree with Broichmore that category names should be as short as possible. Therefor I prefer Category:Smoking men in art above Category:Works of art of men smoking (activity). But sometimes that conflicts with the Universality Principle. So then we should have a discussion about what prevails: short category names or the Universality principle (or any other principle on Commons)? JopkeB (talk) 07:56, 16 July 2024 (UTC)

I likewise agree that brevity is preferable, but not at the expense of clarity. We need to maximize accessibility for all users, not just those of us who have been around long enough to 'get used to' idiosyncrasies. As for changing this category:

1. It seems already agreed to return to 'in art' from 'works of art' in the above linked CfD.
2. Discussion over whether or not (activity) is a useful dab is at Commons:Categories for discussion/2024/07/Category:Smoking (activity), so that dab may also be done away with shortly.

Josh (talk) 13:11, 16 July 2024 (UTC)

The above linked discussion has just come to its conclusion, the rest of the discussion continues here: Commons:Categories for discussion/2024/07/Category:Smoking (activity). ReneeWrites (talk) 05:53, 19 July 2024 (UTC)

What are free media resources for illustrations?

I think illustrations (recent examples) are some of the most useful, most educational, and most needed kind of media on Wikimedia Commons.

What are some good sources for them? Please see Commons:Free media resources/Illustrations which I just created but as of now only has one item.

Moreover, could there be another list for free media resources for datagraphics like charts? Currently, I don't know of many items for such a list either except for Our World in Data. Prototyperspective (talk) 13:19, 15 July 2024 (UTC)

Still only one item. I guess Flickr could be added because there also are illustrations on it, is there some particular tag for these or a subpage? Anything else? Prototyperspective (talk) 19:30, 20 July 2024 (UTC)

July 16

Oak Island's map

Hello, I have a question regarding the Oak Island's map. The map on Commons corresponds to maps from Google Earth and OpenStreetMap.

We are :

• Smith’s Cove = south
• Sheerdam Cove = east
• Sellars Cove = north

These names are included on recent maps found on the web. But when we look for old plans, or in books about the island (page 7), we find:

• Smith’s Cove = east
• South Shore Cove = south
• Joudrey’s Cove = north

Which version is correct? Thanks, Sincerely --Tylwyth Eldar (talk) 15:43, 16 July 2024 (UTC)

@Tylwyth Eldar: why do you think one has to be more "correct"? Names often change over time. - Jmabel ! talk 21:19, 16 July 2024 (UTC)

Bonjour @Jmabel: Thank you for your reply. A place name can evolve over the centuries, but to move like as here with Smith’s Cove, over such a short time? I find that very strange. Such a change doesn't help in reconstructing the history of a place and finding good information. With no explanation for this change, we mix up names and make mistakes. If this change is official, when did it take place? Is there any way to find an official reference ? --Tylwyth Eldar (talk) 18:31, 17 July 2024 (UTC)

Ah, I misunderstood. Well, the page is (semi-)clear about citing its source. "Own work" is dubious for just a crop; it would have been very useful to have a URL link to OSM so it would be easy to see if the labeling has changed there since (it hasn't, and Google Maps has the same for the two coves it labels). {{Fact disputed}} might be in order on both maps we host, noting that they disagree with each other. - Jmabel ! talk 19:19, 17 July 2024 (UTC)

Done and Question asked on the discussion page . Thank you! --Tylwyth Eldar (talk) 05:26, 19 July 2024 (UTC)

July 17

Category:Flickr streams/Category:Photographs by Flickr photographer

You know. Wouldn't it be more efficient if these categories were populated by bots rather than users having to take time off to add the categories manually? Like all images whos author is listed as amaianos would automatically be placed into Category:Photographs by amaianos and etc.--Trade (talk) 00:42, 17 July 2024 (UTC)

@Trade: I'm sure no one would object to a bot filling in any valid category of this sort. Only caution: not every Flickr account corresponds to a photographer, and I've occasionally seen some wrong categories formed on the assumption that they do. - Jmabel ! talk 04:29, 17 July 2024 (UTC)

It's really annoying when you create a FlickR stream category for someone and they already have dozens of photos on Commons Trade (talk) 13:57, 17 July 2024 (UTC)

Agree. And there are more categories like that. The overly manual categorization also means that, at least over time, files are missing in categories when people think it contains all the files for a subject. For example take the category WebM videos which is still added manually and where I pointed this out here with some other example. One could list more examples and this issue relates to a technical idea to fix this issue that I would propose once there is some basic level of tech development or volunteer dev campaigning. If volunteer contributors time spent for such tasks is reduced, they can spend it on other contributions. Prototyperspective (talk) 09:57, 17 July 2024 (UTC)

"why categories for filetypes aren't automatically added". Because links are already overused in Commons. We just had a whole set of changes to reduce the amount of total links because Commons was reaching technical limits of the database. If you want to list video files, you can query the DB table for files, you can filter in the search results and sometimes, you can even use CommonsData. If Petscan doesn't support that... fix Petscan. —TheDJ (talk • contribs) 12:59, 17 July 2024 (UTC)

The fact that categories are easily and visible accessible to everyone and while things like DB tables, CommonsData and etc you have to go out of your way to search for already excludes most visitors and users on Commons.

It's a bizarre design choice if we are supposed to discourage the former in favor of encouraging the later Trade (talk) 14:01, 17 July 2024 (UTC)

I'm not sure what you're saying. Maybe you refer to categories which are links to their respective pages with "links [that are overused]" but I don't know. Filtering for video files only works for search results (especially with the MediaSearch) but not subject-level categories. Not every video about some subject has the search term of that in the title or description (or if it has not necessarily the English one). That would leave searching a category with deepcategory and filtering by filetype. However, that does not work on large categories. If it did, it would need to be made more accessible – subcategories "Videos of…" can be seen and simply clicked but there is no button/dropdown for seeing videos in a category. Yes, already created a petscan issue about it. Prototyperspective (talk) 14:28, 17 July 2024 (UTC)

Category links are the rows in the database used to indicate that a file or page is a member of a category, i.e. if a page is in five categories, there are five category link rows for that page. The total number of category links on Commons is extremely large, to the extent that it causes some performance issues and is blocking changes to category sorting (phab:T362494). New categorization practices which will introduce a large number of new category links, like categorizing files by their file type, need to be avoided. Omphalographer (talk) 00:04, 19 July 2024 (UTC)

Thanks for the clarifications. Videos are already being categorized by their filetype, I was arguing these cats need to be (nearly) complete or they're near useless OR that features like showing only video files are added to petscan / category intersection and these categories be deleted as redundant thereafter (insofar there is no other real value/use of these). In addition, it seems like some technical changes are required, e.g. how this data is stored, cached and read. Prototyperspective (talk) 11:11, 19 July 2024 (UTC)

Mysterious Intel microprocessor/IC

Hi folks!

I recently bought 2 Intel processors (I couldn't resist, as they look so similar to the famous Intel 4004), but I don't know what the purpose could be. Looking at the ceramic package, I can imagine that the product was created maybe between 1972 and 1975. Maybe someone can give a hint?

• 
  Oblique view
• 
  Top view

Thanks and greetings! --PantheraLeo1359531 😺 (talk) 18:26, 17 July 2024 (UTC)

It might be stamped with a manufacturer's part number. You could unsolder one of the lids and look at the die. Glrx (talk) 04:09, 18 July 2024 (UTC)

July 18

Results of Wiki Loves Folklore 2024 is out!

Hi, Greetings

The winners for Wiki Loves Folklore 2024 is announced!

We are happy to share with you winning images for this year's edition. This year saw over 41,038 images from 1921 uploaders represented on Commons in over 140 countries. Kindly see images here.

Our profound gratitude to all the people who participated and organized local contests and photo walks for this project.

We hope to have you contribute to the campaign next year.

Thank you,

Wiki Loves Folklore International Team

Rockpeterson (talk) 08:25, 18 July 2024 (UTC)

empty sub-categories of Category:EuroGames_2024_Vienna

Please do not delete empty sub-categories of Category:EuroGames_2024_Vienna as we have live event action for next 5 days and many sub-categories will be populated even if you find them empty. Thank you for understanding on behalf of #WikiLovesPride organizers. -- Zblace (talk) 10:11, 18 July 2024 (UTC)

Book covers' copyright

Hello! I'm the project manager of WoALUG and we're thinking of holding a GLAM project with a local museum. Can anyone advise me about what kind of book covers I can and cannot upload here and how exactly to do that? Thank you in advance!. --Vyolltsa (talk) 10:41, 18 July 2024 (UTC)

COM:BOOK is a brief summary about the matter. --Geohakkeri (talk) 10:44, 18 July 2024 (UTC)

Wikimedia Movement Charter ratification voting results

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

Hello everyone,

After carefully tallying both individual and affiliate votes, the Charter Electoral Commission is pleased to announce the final results of the Wikimedia Movement Charter voting.  

As communicated by the Charter Electoral Commission, we reached the quorum for both Affiliate and individual votes by the time the vote closed on July 9, 23:59 UTC. We thank all 2,451 individuals and 129 Affiliate representatives who voted in the ratification process. Your votes and comments are invaluable for the future steps in Movement Strategy.

The final results of the Wikimedia Movement Charter ratification voting held between 25 June and 9 July 2024 are as follows:

Individual vote:

Out of 2,451 individuals who voted as of July 9 23:59 (UTC), 2,446 have been accepted as valid votes. Among these, 1,710 voted “yes”; 623 voted “no”; and 113 selected “–” (neutral). Because the neutral votes don’t count towards the total number of votes cast, 73.30% voted to approve the Charter (1710/2333), while 26.70% voted to reject the Charter (623/2333).

Affiliates vote:

Out of 129 Affiliates designated voters who voted as of July 9 23:59 (UTC), 129 votes are confirmed as valid votes. Among these, 93 voted “yes”; 18 voted “no”; and 18 selected “–” (neutral). Because the neutral votes don’t count towards the total number of votes cast, 83.78% voted to approve the Charter (93/111), while 16.22% voted to reject the Charter (18/111).

Board of Trustees of the Wikimedia Foundation:

The Wikimedia Foundation Board of Trustees voted not to ratify the proposed Charter during their special Board meeting on July 8, 2024. The Chair of the Wikimedia Foundation Board of Trustees, Nataliia Tymkiv, shared the result of the vote, the resolution, meeting minutes and proposed next steps.  

With this, the Wikimedia Movement Charter in its current revision is not ratified.

We thank you for your participation in this important moment in our movement’s governance.

The Charter Electoral Commission,

Abhinav619, Borschts, Iwuala Lucy, Tochiprecious, Der-Wir-Ing

MediaWiki message delivery (talk) 17:51, 18 July 2024 (UTC)

Freedom of panorama for photos taken across the border

Specifically about this image, but since it seems to be a more general topic, I'll ask at the village pump. This photo shows the architecture of Myanmar, taken from across the border in Thailand. While Myanmar does not allow freedom of panorama, Thailand does. What is the copyright status of such pictures? --Nux-vomica 1007 (talk) 22:48, 18 July 2024 (UTC)

@Nux-vomica 1007 see COM:FOP#Choice of law. There have been instances of accepting South Korean buildings that were taken from the North Korean side, using NoKor copyright law that is more lenient on reproductions of buildings (something that SoKor law prohibits if the images are reproduced as copies to be sold). Perhaps we may use Thai FoP in this case, unless the architect of those buildings who knows about Burmese law sends a cease-and-desist letter to Wikimedia, but for now the chances of this happening is low. JWilz12345 (Talk|Contrib's.) 02:02, 19 July 2024 (UTC)

Thank you very much. I did not realize that there was a clear answer in the document. Nux-vomica 1007 (talk) 03:02, 19 July 2024 (UTC)

@JWilz12345: Similar cases also occurred at Three Countries Bridge, a bridge that crossed France, Germany and Switzerland, in which France has no FOP, and the latter two has. --A1Cafel (talk) 05:59, 19 July 2024 (UTC)

July 19

Glitch

Tracked in Phabricator
Task T370304

I’m getting this (with varying timestamp and UUID, of course):

MediaWiki internal error.
 
Original exception: [c8480c01-eec0-4e32-bcc2-c880ee466574] 2024-07-19 00:26:48: Fatal exception of type "Wikimedia\Rdbms\DBUnexpectedError"
 
Exception caught inside exception handler.
 
Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.

at every other page I try to load, both in Commons and pt.wp. -- Tuválkin ✉ ✇ 01:01, 19 July 2024 (UTC)

Same here, though not as often as you have experienced. Josh (talk) 15:30, 19 July 2024 (UTC)

This is a Wikimedia wide issue, see linked Phabricator task. — Speravir – 23:57, 19 July 2024 (UTC)

Video question

https://vimeo.com/986935006 (my own work). Am I correct that the visual portion of this would be OK to free-license and upload to Commons, but not the audio? - Jmabel ! talk 06:36, 19 July 2024 (UTC)

• Looks okay to me, the structures are obviously old enough, and due to the lighting conditions and the principle of a "Beiwerk", I don't see problems with personality rights --PantheraLeo1359531 😺 (talk) 07:23, 19 July 2024 (UTC)
• Not hearing much back, I guess I'll assume I got this right, and if I'm wrong someone can always DR. Thank you PantheraLeo1359531 for weighing in. - Jmabel ! talk 19:06, 19 July 2024 (UTC)

I guess there are plenty of videos like these on the internet :) --PantheraLeo1359531 😺 (talk) 19:08, 19 July 2024 (UTC)

Pre-implementation discussion on cross-wiki upload restriction

Tracked in Phabricator
Task T370598

The proposal to restrict non-autoconfirmed users from using cross-wiki upload tools has received unanimous support so far, despite proposer's attempts to withdraw the proposal. Do I need to notify all wikis at Tech News or something? Actually, I'm thinking about writing a Phabricator task requesting implementation of such restriction. Furthermore, I'm unsure whether re-proposing this at Meta-wiki is necessary. George Ho (talk) 07:05, 19 July 2024 (UTC)

It was already in the m:Tech/News/2024/29. But we should of course add it again when we have the final date when it comes into force. The idea was to simply do this with a abuse filter as a new functionality for this might take a while to be developed. The other changes need to be done on the lokal Wikis. GPSLeo (talk) 08:10, 19 July 2024 (UTC)

I'm not sure how that will work. What will "the other changes" look like? Isn't it going to require a large scale coordination with sister projects and local sysops, or otherwise cause a major disruption in that many new users will still be invited to do cross-wiki upload locally, prepare uploads, and be told "sorry, you cannot do that" at the end of the workflow? It seems like we need some significant time investment in any way. whym (talk) 11:37, 19 July 2024 (UTC)

The warning that the tool only works if the user was on Commons before and has the rights can simply be added to the default text of mw:Manual:$wgUploadDialog. If local Wikis have overwritten the default text they need to make the change locally. GPSLeo (talk) 14:10, 20 July 2024 (UTC)

Can you suggest an example of the warning text? Will it be clear if the user is allowed to upload or not, and where is the workaround if they are not allowed to proceed? (Something along the lines of "Click here (link), and if it says ___ you cannot upload", "You can still upload if you go to ___"?) Note that not every average user understands what "autoconfirmed" means, or how their centralauth-connected accounts work. I think many will be surprised to see they have "new" Commons accounts when they have contributed to Wikipedia for a long time. whym (talk) 01:36, 21 July 2024 (UTC)

@GPSLeo: All right. Abuse filter first then. After that, "the other changes" can be proposed then, but I think Meta-wiki RFC is one of best options, especially for larger wikis, for central discussion. Unsure why this matter should be resolved locally. George Ho (talk) 00:12, 20 July 2024 (UTC); amended per replies below, 18:28, 20 July 2024 (UTC)

After the tech news and the message on m:Wikimedia Forum there were no responses from other projects. Therefore I think the other projects do not really care about this and therefore I think an additional RFC on Meta is not needed. GPSLeo (talk) 14:05, 20 July 2024 (UTC)

+1. Having an RfC about it on Meta-wiki is super redundant at this point. There's been more then enough time and cross project notifications for people from outside of Commons to comment on this if they wanted to. --Adamant1 (talk) 14:58, 20 July 2024 (UTC)

This phab ticket has been made: phab:T370598. --George Ho (talk) 22:14, 21 July 2024 (UTC)

July 20

Croptool

I'm not sure if this is just an issue that I have or whether everyone else on Commons has the same problem. On https://croptool.toolforge.org/ I have successfully used this tool for sometime, but now the "Preview" button is not working. I have tried for over a week now without any success. Can you please give me some advice. Thanks. SethWhales ^talk 17:24, 20 July 2024 (UTC)

@Seth Whales: see Commons_talk:CropTool#Broken. - Jmabel ! talk 19:25, 20 July 2024 (UTC)

@Jmabel: Thank you. SethWhales ^talk 05:00, 21 July 2024 (UTC)

Political donation from Thomas Crooks - public record image

Greetings, regarding:

• File:FEC Thomas Crooks Donation 202102049425215728 189746.pdf and its derivative,
• File:FEC Thomas Crooks Donation Cropped.jpeg

This is a freely available, public domain government record reflecting "evidence" in the Trump assassination case, specifically the suspect's donation to a political cause. It's been added, removed, perhaps deleted here, and hotly contested in a few areas, but I'd like to bring that debate back to the source.

• On enwiki, en:WP:BLPPRIMARY demands that we can never use primary sources, especially public records, to document a BLP; BLP still applies to Crooks and his family, as well as everyone else involved in the July 13 event.

• There is absolutely no useful information in this image that isn't reflected by secondary, reliable, textual records in news outlets, etc.

• It appears that most or all other "public records" such as photos of Crooks have been deleted from Commons; indeed, they've been replaced and deleted more than once.

• It simply feels creepy and invasive to hold up this paper and say "look look" without any real context or analysis. We've also got to consider en:WP:BLPPRIVACY, even though the document is so thoroughly redacted it's nearly useless.

• I am not sure what deletion criteria to use, and I'm hesitant to start a deletion discussion yet before we've gauged consensus and established a concrete rationale for that. So, thoughts? Elizium23 (talk) 21:29, 20 July 2024 (UTC)
  • I can't see the relevance of the fact that en-wiki does not generally allow primary sources as citations. Commons consists overwhelmingly of primary-source material.
  • It is no more being "h[e]ld up and say[ing] 'look look'" than any other image on Commons.
  • In short, I can't imagine any reason to delete it. How are you saying it differs from, for example, Lee Harvey Oswald's Social Security card, which we have hosted for over a decade? - Jmabel ! talk 22:08, 20 July 2024 (UTC)

Enwiki's policies aren't very relevant for what is and isn't allowed to be hosted on Commons. Commons is mostly concerned with whether images are within the scope of their own project, and whether these media files are freely licensed (you can read about the project scope more here: COM:SCOPE). Images of Thomas Crooks uploaded to Commons were probably deleted for not being released under a free license.

Considering this image is in the public domain, you could only argue it being out of scope to have it deleted, but considering the widespread use it sees across various wikiprojects (not just the English-language one) I don't think you'll have much success there. You could argue for it to be taken down from the enwiki page specifically for being a primary source, but you'd have to make that case there. ReneeWrites (talk) 07:39, 21 July 2024 (UTC)

@Elizium23, Jmabel, and ReneeWrites: I nominated the pdf file for deletion. Regarding the second image, I agree with ReneeWrites. Since it is in use in several articles, it is clearly in scope and there is no valid reason to delete. SCP-2000 15:24, 21 July 2024 (UTC)

I've seen both files and I find them very interesting. I didn't know how political donations in the US looked like (and I don't know if there is any form like that in Spain). So -beyond the shooting and all that- is formative, it improves my knowledge, and therefore I think it's worth being in Commons. Maybe an empty form would be better. But as for now, that one works. B25es (talk) 06:33, 22 July 2024 (UTC)

July 21

Error during upload

Hello, I got some error during upload and these files is not possible finish correctly: File:Nové značení v LN - kotoučky 01.jpg and File:Nové značení v LN - kotoučky 02.jpg. Do somebody know what to do? Is it possible to edit these pages and add description and categories or somebody have to delete it first? Thank you. Palu (talk) 01:44, 21 July 2024 (UTC)

@Palu: just copy-paste the wikitext from a file page for another of your uploads and edit accordingly. No one can do this for you, because only you can grant the license. - Jmabel ! talk 03:08, 21 July 2024 (UTC)

No, editation is not possible due to error: "In order to edit the page, you must first load the file." Palu (talk) 08:57, 21 July 2024 (UTC)

There was some bug but I was able to create the pages. Now you can add the correct content. GPSLeo (talk) 09:16, 21 July 2024 (UTC)

Thank you, now worked perfectly, done. --Palu (talk) 11:31, 21 July 2024 (UTC)

What are outgoing and incoming wikilinks?

What needs to be done to get pages out of "Pages where lack of wikilinks indicates a problem"? (Source: Commons:Editor's index to Commons)

• Special:DeadendPages – pages with no outgoing wikilinks
• Special:Lonelypages – pages with no incoming wikilinks ("orphan" pages)

1. What are outgoing and incoming wikilinks exactly?
2. Do these gallery pages just need categories (which a lot of them got a long time ago, but they still continue to appear on this list), do they need a Wikidata Infobox, or something else?

JopkeB (talk) 10:05, 21 July 2024 (UTC)

I think on Commons these are not a problem. We don't particularly interlink our galleries. Of course, on other wikis where the analogous space is "article space", the same thing would represent a problem. - Jmabel ! talk 19:17, 21 July 2024 (UTC)

@Jmabel: Thank for your reaction. Next question: are these two Special pages still needed on Commons? JopkeB (talk) 04:55, 23 July 2024 (UTC)

I see no purpose for them. - Jmabel ! talk 19:13, 23 July 2024 (UTC)

@Jmabel: So they might be deleted. What is the deletion procedure for such pages? Where can I drop a request for deletion? JopkeB (talk) 10:42, 25 July 2024 (UTC)

Not sure it's worth the effort, but you could probably file something in phabricator, or you could ask at COM:Village pump/Technical. That is, presuming no one would object; it might be worth running this by COM:Village pump/Proposals first to see if someone disagrees. - Jmabel ! talk 17:42, 25 July 2024 (UTC)

Sounds good. If you find some other that are not really useful here, please have them deactivated too.

You could also add some info to: MediaWiki:Deadendpages-summary, MediaWiki:Deadendpagestext displayed on Special:DeadendPages, etc. Enhancing999 (talk) 18:30, 25 July 2024 (UTC)

Appropiate mother-cats🐈 for Category:Intel 8286

Hi!

I am looking for fitting mother-cats of Category:Intel 8286. Intel 8286 is a so called "bidirectional bus driver", but I am failing to find good cats. Maybe it would even qualify as some type of microprocessor. Anyway, hardware drivers only refers to software working as driver, and the bus driver means usually a person who controls the bus while driving. Thanks!

Greetings --PantheraLeo1359531 😺 (talk) 10:07, 21 July 2024 (UTC)

@PantheraLeo1359531: It should be in several categories under Category:Integrated circuits. Category:Intel integrated circuits is an obvious one. Which category under Category:Integrated circuits by function is less clear. Comparing the 8286 datasheet with my trusty 74-series TTL Data Book, it looks like the 8286 is pretty similar to the to the 74LS245, which Commons categorises under Category:YES gates and Category:Bus transceiver integrated circuits. Those seem like good categories, so I'd put the 8286 in both of them as well. --bjh21 (talk) 13:19, 21 July 2024 (UTC)

Thank you, this is a very detailed answer :) --PantheraLeo1359531 😺 (talk) 13:48, 21 July 2024 (UTC)

Extracted file deleted

The file linked below was extracted from File:GP2303 092018SMG 6499 (1).jpg which is deleted for "No permission since 20 May 2023". How is this file allowed to be kept but not the original one?

File:Oscar Piastri at the 2023 Australian Grand Prix.jpg // Kakan spelar (talk) 17:36, 21 July 2024 (UTC)

@Kakan spelar: I don't see what here calls for a general discussion. Is anything stopping you from nominating it for deletion? - Jmabel ! talk 19:19, 21 July 2024 (UTC)

@Jmabel: No not really, just wanted to know if this was a mistake or why it was still up. I guess I'll nominate it for deletion then. // Kakan spelar (talk) 19:44, 21 July 2024 (UTC)

July 22

Commons Impact Metrics now available via data dumps and API

Hi all! I just wanted to let you know that we published a blog post about the new Commons Impact Metrics, a new data product offering monthly data dumps and a new Wikimedia Analytics API for Wikimedia Commons categories of images relating to cultural heritage. These categories include content from libraries, museums, and archives but also visual documentation of natural, built, and living heritage.

Using this data, Commons contributors and their partners can count monthly edits in a category; identify their most active contributors and most viewed files; and understand which Wikimedia projects, languages, and articles are using their images.

You can read more about it (and share it with your partners, if interested) at diff.wikimedia.org. --Sannita (WMF) (talk) 14:11, 22 July 2024 (UTC)

Adding an artist to an image within Wikidata

Does anyone know how to do this? See image. Everything in this German newspaper has been made un-editable by the common man. Unless, whoever is converting all these files to sole control by WD, takes responsibility for making these entries perfect, then maintenance here, is hopeless. Who, even, is doing this? Broichmore (talk) 16:47, 22 July 2024 (UTC)

@Cryptic-waveform: : your template, so you can presumably answer better than anyone else. - Jmabel ! talk 17:24, 22 July 2024 (UTC)

It looks to me like author = {{various}} is hardcoded in the template with no override possible, which I think should not be the case. - Jmabel ! talk 17:25, 22 July 2024 (UTC)

Hello. First of all I've only modified the file to use a more general template rather than a template-by-year, to remove duplicate code and differences between templates. Additionally I've also extensively documented the template.

As for the question of why, there are a lot of benefits to the current approach. It ensures that all files looks similar, link to previous and next page, and automatically link extracted images.

@Broichmore: : What change are you trying to make? I can look into making it possible. Cryptic-waveform (talk) 20:06, 22 July 2024 (UTC)

Small questions, potentially big answers.

I'm concerned with images, rather than pages.

Most of these points are covered in the existing artwork template.

Regarding engravings, We, would want to include for, the engraver/etcher, the artist of the intermediate drawing, and the author of the original sketch, photographer, painter, or sculptor.

We would want to include for caption (title), ability to augment the description. Adding translations of same.

Perhaps, issue number, page number, volume number.

Expanding on the date, if known.

Adding in depicted place or people? Place of creation? Credit line?

Flexibility on choice of License?

As to the benefits? The artwork template already makes one file look similar to another, and automatically links extracted images.

I understand? your idea for the use of templates. However, in the long term, what we need to do is have choice of license linked in some way to last or most appropiate creator. Wikidata could do that, because it contains death date, citizenship, and workplace. Broichmore (talk) 08:44, 23 July 2024 (UTC)

The Gartenlube, has drifted away, from how we treat newspapers of this era on the project. One thing thats needs cleaning up, is this page, and how the all date cats on it are sorted. See 1920 in particular. Can you fix?

Already Gartenlaube images suffer from very little or no content development. It's not a place for casual visitors. It's very niche, only really accessible to editors with a German background and language, and we don’t have enough of them. It's use of gothic script, and the way that artists and engravers signed work their work, makes for highly specialized work.

French periodicals, suffer from a similar lack of interested contributors, only they don’t use a difficult typeface, and they don’t have the added handicap, IMO of being Wikidata centric. Broichmore (talk) 09:10, 23 July 2024 (UTC)

To sum up, the kind of people, who can easily read the text and identify the artists are not the kind of people, that relate to, or want to be tied up in wikidata. Broichmore (talk) 09:13, 23 July 2024 (UTC)

Location

The text: 'This photo is taken in the train.' is not very informative. The line diagram may give a clue.Smiley.toerist (talk) 20:38, 22 July 2024 (UTC)

PS: I started a new category: Category:Rail vehicle floors. Smiley.toerist (talk) 20:40, 22 July 2024 (UTC)

These are MTR C-stock trains in Hong Kong. I've categorized and edited descriptions appropriately. Pi.1415926535 (talk) 20:53, 22 July 2024 (UTC)

(edit conflict) As a wild guess, C Train might refer to TML C-train. --Geohakkeri (talk) 20:54, 22 July 2024 (UTC)

I don't undertand why? Every room has a floor. Train seating is more descriptive here than floor. There was nothing wrong with Category:Train interiors. Broichmore (talk) 07:44, 23 July 2024 (UTC)

The floor category is only for images where the floor is prominent such as File:Osaka metro floor 2024.jpg. I draw the line at showing substantial amount of floor. There are also images showing no floor but the roof File:Chichibu Railway 7000 series interiors 1.jpg Smiley.toerist (talk) 08:13, 23 July 2024 (UTC)

July 23

Should documentation start recommending AV1 over VP9?

Pages like Help:Converting video, Commons:File types, etc. generally recommend uploading in VP9/Opus/WebM. In particular, FT bases this off of the MDN Web Docs, which now recommends VP9 for "everyday" video and AV1 for "high quality" video. I think that we, a free file repository, generally fall into the "high quality" bucket (or, that is at least what we try to be, whether or not we get anywhere close is another story). AV1 probably has better support than VP9 at this point... probably, I can't find any good sources with numbers. It also has the bonus of being much simpler, cf. Help talk:Converting video#ffmpeg guidance. Snowmanonahoe (talk) 00:07, 23 July 2024 (UTC)

References

Is it also well usable in FFMPEG? My last level of knowledge is that it is in an experimental phase. I think this would be an important parameter, when working with AV1 --PantheraLeo1359531 😺 (talk) 13:14, 23 July 2024 (UTC)

I've never seen anything that indicates that AV1 support is experimental. I doubt that's still the case as it's been around for six years at this point. Snowmanonahoe (talk) 19:33, 23 July 2024 (UTC)

AV1 works, you can use it. We even serve up all video content in AV1 whenever a browser supports it. —TheDJ (talk • contribs) 13:51, 24 July 2024 (UTC)

Overlapping templates

Any reason for both Template:Videos from country by year and Template:Videos from the United States by year to exist?--Trade (talk) 03:19, 23 July 2024 (UTC)

Category:Videos by subject

Is there any guidelines or consensus as to how granular the subjects of this category should be? Trade (talk) 04:18, 23 July 2024 (UTC)

I think the general categorization guidelines apply here. The subjects can be as granual as they can get, provided you don't end up with a whole bunch of categories with only 1 media file (Commons doesn't have an official guideline for this I believe, but generally speaking the minumum number of media files should be 3). If a lot of categories share a common trait they can be put in a container category. ReneeWrites (talk) 09:40, 23 July 2024 (UTC)

Less granular than most categories we already have :) —TheDJ (talk • contribs) 13:50, 24 July 2024 (UTC)

Task — Wikimedia logos categorisation

yesterday I wanted to find logos for each Wikimedia project sorting by language and I discovered that there wasn't a category for that (no one shows love to the sister wikis other than Wikipedia). I went ahead and created one and I am creating a discussion to drive more people to help as I won't be able to alone.

you can see the problem below and on Category:English Wikimedia logos, as of course, English has the most work done

Wikimedia logos by language‎ (13 C)

hope this is something that gets people interest. Juwan (talk) 21:01, 23 July 2024 (UTC)

Managing overpopulated categories

Hello! There are many categories containing hundreds or thousands of files but no subcategories. In some cases, I've found that templates like {{ImageTOC}} make these categories a lot more navigable for future subcategorization, but only if most files are named in a way that allows for it.

What other ways are there to make manually sorting files a bit more manageable? Is it, for example, somehow possible to order images in a given category by the date= parameter in {{Information}} so that they can be more easily sorted into by-year categories? Sinigh (talk) 21:10, 23 July 2024 (UTC)

@Sinigh: Can you give any examples of these categories? That would make it easier to discuss what to do. In most cases, subdividing by date is not the most useful; it's better to subdivide by subject. Pi.1415926535 (talk) 23:20, 23 July 2024 (UTC)

@Pi.1415926535: Yes, "by subject" is of course the most useful one. Here are a few different examples:

• Category:Mountain Warfare Training Center – "by year" goes a long way since the category itself is both location and general subject  Done
• Category:Photographs by Holger Ellgaard – "by subject", but it's probably a good idea to begin with "by year/month" because of the large number of files
• Category:People wearing boonie hats – I don't know what to do here, but most or all photos seem to be from the US military, so maybe that and then "by service"?

Since images have dates and are in other categories that define their subjects, I'm essentially wondering if this could somehow be used to make sorting easier. Bit of a vague question and a long shot. Sinigh (talk) 02:15, 24 July 2024 (UTC)

If topical categories can be broken down by subject, this should be done. Another possibility is by view. I think it's generally a non-issue.

The "Mountain Warfare Training Center"-category may be an illustration of what shouldn't be done: make subcategories by date rather than topical categories:w:Mountain_Warfare_Training_Center#Installation_capabilities can provide suggestions for topics. "Winter" could be another option.

Personally, I think it's terrible habit to make subcategories by subject in photographer categories. Enhancing999 (talk) 10:13, 25 July 2024 (UTC)

What I'm asking for here isn't advice on appropriate subcategories. As for the actual topic of this discussion, I suppose going through images manually and using Cat-a-lot will have to do. Sinigh (talk) 11:48, 25 July 2024 (UTC)

I don't think it's a good idea to break down a user's category merely because you think it's "overpopulated" and you found a tool to do so. Enhancing999 (talk) 11:52, 25 July 2024 (UTC)

And I agree. What do you mean by "a user's category"? Sinigh (talk) 14:36, 25 July 2024 (UTC)

The one above where you mentioned: "it's probably a good idea to begin with "by year/month" because of the large number of files". No. Enhancing999 (talk) 14:38, 25 July 2024 (UTC)

Of course, I misunderstood. Ellgaard was indeed a Wikimedia user late in life, but he was also a photographer for over half a century. That category was created by someone else almost a year after he passed away. I assume that most of his contributions are relatively recent creations intended for Commons, but his uploads are from the 1950s and onward, so I thought (perhaps mistakenly) that chronological categories would be useful there. Sinigh (talk) 14:58, 25 July 2024 (UTC)

Such a feature would indeed by very useful. Does somebody have a phab issue about that, probably it has been proposed already earlier.

One can only sort by upload date by using incategory:"Cat name" (or deepcategory if it has few subcats) and then sorting the results accordingly, but one can't do so for the data in the Date field.

However, your examples really aren't good and only highlight why it may be important to clear a few things up before such is enabled – I agree with Enhancing999 that files in 'photographs by {name}' cats for example shouldn't be subcategorized by date or subject.

There's many cases where the year or decade would be very useful to have as subcat. Moreover, in many cases such subcats already exist but miss many files which could more easily be fixed if this feature was there. A main issue is that having so many subcats make things often more cumbersome than being helpful to 1) the user seeking images (e.g. any high-quality ones) and 2) contributors seeking to populate/complete a cat where relevant files are buried in deep subcategories rather than being at the top-level; and I have proposed a remedy for that via a proper deepcategory wall-of-images view for cats. Likewise, being able to sort by date in a given cat would also be helpful for users seeking images...especially when for example looking for a recent statistic and a good example is Category:Commons statistics which has many files but most of them being quite old. Prototyperspective (talk) 12:29, 25 July 2024 (UTC)

Oh, I'm not particularly invested in the subcategories I suggested above! I just gave a few different examples of categories because I was asked to, and added a few potential subcategories to quickly show what I was hoping could be done. I did not wish to say or imply that the categories must be structured that way. I'm just here asking for that sorting feature, or method, or any other ideas anyone may have.

But I can definitely see how it seemed that I was arguing for a particular kind of categorization. I hope you can now rest assured that I'm not. (One of the categories has since been divided into subcategories, but not by me.)

I think it's unfortunate that categories like the Ellgaard one aren't very navigable, though. If it shouldn't be subcategorized by date or subject, what then should be done? Should it be left the way it is, with tens of thousands of images all in one place?

As for images being buried in deep subcategories, that is most certainly a problem and a valid complaint, but I always assumed we could have it both ways. Shouldn't it already be possible to automatically sort all images under e.g. "Photographs by John Doe" into a category like "All photographs by John Doe"? Isn't that essentially what happens in flat-list metacategories, like Category:Categories by setting (flat list)? I'm sure there are several other possible or existing solutions that I'm unaware of; this is just one example.

Sinigh (talk) 14:34, 25 July 2024 (UTC)

Sure, I see, this was basically just meant as a note regarding these examples, I didn't took them as being very intentionally chosen or anything of that sort.

In regards to your question of what should be done my proposal in the tech survey mentioned that it could be sortable by number of file uses on Wikipedia or similar things so that most relevant or highest quality files show at the top. Shouldn't it already be possible to automatically sort all […] into a category like "All photographs by John Doe"? good question and I wondered about things like that but currently it's not done and is asked to not be done by COM:OVERCAT. If the category tree is not too deep or the deepcategory search operator is improved one can already see all files in a category branch in one place so this is redundant so I don't think deviation from (a change to) that Commons policy would be a good approach.

On a related note, one thing that seems more considerable is whether files should be removed from a higher level of a category once it's in any subcategory of it or only once its main aspects related to the broader category are captured by subcategories. For example: if a category has subcategories by country/location and by year, should the file already be removed from the broad category once it's in a by-year category (but missing in the by country one)? I think not, but that's probably a topic for another day of which there are too many (topics/tasks not days per contributor). Prototyperspective (talk) 15:13, 25 July 2024 (UTC)

July 24

My historic .svg Inkscape images now showing as blank

Hello, I have been uploading .svg Inkscape coats of arms images for many years. Suddenly now many of them are showing up on Commons as blank shields. For example File:FinchArms.svg. To test it and examine it I saved the blank image from Commons back to my computer, and when I opened it on my Inkscape package, it showed up properly. So the image is still in there somewhere! Can anyone suggest what might have happened, and how to fix the problem? Probably many hundred of my images over many years have been affected, from a brief review of my upload history.Lobsterthermidor (talk) 14:52, 24 July 2024 (UTC)

@Lobsterthermidor: Over time, the software to "render" SVGs (turn SVGs into PNGs shown to users) changes. I'm not a particular expert on SVGs, but I recall that Inkscape's SVGs often have issues in practice over time. If you export as "Plain SVG" I think they will work correctly. Jdforrester (WMF) (talk) 17:02, 24 July 2024 (UTC)

Maybe add a gif version if svg keeps breaking? Enhancing999 (talk) 18:23, 24 July 2024 (UTC)

Gifs in 2024? Sjoerd de Bruin (talk) 18:29, 24 July 2024 (UTC)

Replacing vector files with bitmap files is going backward. Just fix the SVG files. Glrx (talk) 19:46, 24 July 2024 (UTC)

It's an Inkscape bug that is now apparent because WMF uses a stricter SVG rendering engine. The files also do not display on Chome.

Inkscape emits illegal clipPath elements. For example, FinchArms.svg has

    <clipPath clipPathUnits="userSpaceOnUse" id="clipPath2877">
      <g id="g2881" inkscape:label="Layer 1" transform="matrix(0.28222223,0,0,0.28222223,-7.7612925,19.376908)" style="fill:none">
        <path sodipodi:nodetypes="ccscssc" inkscape:connector-curvature="0" id="path2879"
           d="M 79.678451,149.81749 H 646.03583 v 258.58398 c 0,285.48607 -283.17773,397.82031 -283.17773,397.82031 0,0 -196.71555,-78.03561 -262.23435,-269.31836 C 87.532751,498.68407 79.678451,455.94392 79.678451,408.40147 Z"
           style="opacity:1;fill:none;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:3;stroke-linecap:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
      </g>
    </clipPath>

A clipPath element may not contain a g element. It is only allowed to contain simple shapes such as circles, rectangles, and paths (and a little more).

Glrx (talk) 19:46, 24 July 2024 (UTC)

Thanks for that explanation. Unfortunately I'm not a computer programmer, merely an amateur heraldic artist who has devoted hundreds of hours to creating images for Commons, which always used to show up without any problems. It would be impossible for me to go back over my work of a decade altering the computer code. It seems that the error is on the part of the WMF switching to a "stricter SVG rendering engine". Shouldn't they have considered what effect that might have on existing images? Surely Commons would want to retain all work that has been submitted to it? We trust Commons to value and to securely store and protect our work, not to trash it because they want to move to the inevitable next technological standard? What can be done to bring this problem to the notice of the powers that made this change? Many thanks,Lobsterthermidor (talk) 11:58, 25 July 2024 (UTC)

@Lobsterthermidor: It is not WMF's fault but rather Inkscape's fault. The files were never legal SVG 1.1. https://www.w3.org/TR/SVG11/masking.html states

A ‘clipPath’ element can contain ‘path’ elements, ‘text’ elements, basic shapes (such as ‘circle’) or a ‘use’ element. If a ‘use’ element is a child of a ‘clipPath’ element, it must directly reference ‘path’, ‘text’ or basic shape elements. Indirect references are an error (see Error processing).

Any file with this bug will not validate.

It is not upto WMF or Gnome (the author of the render that WMF uses) to accommodate Inkscape's errors.

Inkscape should be told of the error, and Inkscape should figure out how to fix its tools and the faulty files it produced.

I will fix the FinchArms SVG.

Glrx (talk) 16:51, 25 July 2024 (UTC)

User:Glrx, that is very much appreciated. I have been uploading files like File:FinchArms.svg for many years with no problems at all. What can I do about the several hundred other images I have uploaded which are now blank? Surely this is the result of some recent change made at WMF, which now handles such files differently? Can I try to persuade the person responsible for making this change to keep the old "SVG rendering engine" as an option? Are they aware that the change they have made will be affecting files in this way? Surely I cannot be the only person affected? Thanks again for your invaluable help.Lobsterthermidor (talk) 17:05, 25 July 2024 (UTC)

@Lobsterthermidor: I understand your frustration, but think about what you are asking. The broken SVG files also do not display on Chrome; are you going to ask Chrome to modify its browser to also display your files? Commons wants files to not only display as expected on Commons, but also in browsers all over the world. Things should be fixed where they are broken, and the broken parts here are the SVG files.

I believe there are thousands of SVG files on Commons that will no longer render correctly. That hurts. But those files also do not display correctly on Chrome. The files need to be fixed. The renderer is not broken. Files that violate the SVG specification may not display as we expect.

WMF going back to an old renderer is not a solution for other reasons. The renderer has many other bugs that the newer version fixes. The current version does a much better job at supporting CSS. Furthermore, the current WMF renderer is still out-of-date by several years. We want WMF to update to even more recent renderers rather than going back to one that is essentially 6 years old.

Yes, it is frustrating. But it is not WMF's fault: it is Inkscape's fault.

Glrx (talk) 18:13, 25 July 2024 (UTC)

July 25

Need help with correct naming

Hello, I was searching for Czech term "výstaviště" and its category here - výstaviště is place for exhibitions (and sometimes can be also for lunaparks, food festivals, etc.). First my opinion was that in english it is Category:Fairgrounds but according to dictionaries this is only for lunaparks. So I found english term Exhibition grounds and made category. But then I was searching and searching and according this it looks that Fairgrounds is for exhibitions and also lunaparks, not only lunaparks. So I can use this already existing tree of categories. Am I right or...? (if you can, you can shift categories to correct naming immediatelly if its wrong). Thank you very much for your help and sorry for my bad dictionaries :D Palu (talk) 00:57, 25 July 2024 (UTC)

@Palu: May I assume that by "lunapark" you mean "amusement park"? "Amusement park" is not really interchangeable with "fairgrounds". Disneyland is an amusement park, but not a fairground. Fair Park in Dallas is a fairgrounds, but only once a year, as far as I know, does it host anything like an amusement park. - Jmabel ! talk 04:20, 25 July 2024 (UTC)

Yes, correct. So what term is best for "místa kde se dějí primárně výstavy"? Thank you for your help and patience :) --Palu (talk) 06:43, 25 July 2024 (UTC)

So in the end I used artificial intelligence and it told me that both terms are interchangeable, however "exhibition grounds" is more exclusively for exhibitions, while "fairgrounds" is more benevolent (also for entertainment), therefore more universal. So I will unify it on the "fairgrounds". If somebody will evaluate better solution, feel free to correct it. Thank you for your help provided. --Palu (talk) 07:23, 25 July 2024 (UTC)

Image Annotation

Hey All We at Wiki Project Med have funded an image annotation tool that meshes with Commons. It is still a little rough around the edges with further ongoing development. If you have suggestions please add them here Doc James (talk · contribs · email) 02:06, 25 July 2024 (UTC)

I totally don't understand what this does. I put in the name of a file on Commons and it offered to upload it to Commons. - Jmabel ! talk 04:23, 25 July 2024 (UTC)

@Jmabel: It looks like the tool works if you just copy and paste the URL for the page instead of the actual image. --Adamant1 (talk) 04:47, 25 July 2024 (UTC)

I can still make no sense of what the tool is supposed to do. It seems to be offering to upload the image over itself. - Jmabel ! talk 17:49, 25 July 2024 (UTC)

@Jmabel:

My take is the tool is a simple web-based graphics editor. The goal of the editor is to take bitmap files (e.g., a JPEG medical image), and add leader lines and text labels to that bitmap (e.g., labeling muscles). After editing, the file can overwrite the original on Commons or write to a new location.

Think about downloading a bitmap file to a Windows machine, using MS Paint to add some text, and then reuploading the file to Commons.

Glrx (talk) 18:23, 25 July 2024 (UTC)

So this is for on-image annotations? And if you overwrite with it on anyone's images except your own, you are almost always violating policy? - Jmabel ! talk 18:49, 25 July 2024 (UTC)

@Doc James: Glrx (talk) 19:47, 25 July 2024 (UTC)

URAA-restored copyrights of old European postcards

Moved to Commons:Village pump/Copyright Smiley.toerist (talk) 11:39, 25 July 2024 (UTC)

New Light rail station in Hannover

This is a new Light rail station in Hannover, that is not yet present on the OpenRailwayMap. It is on the Empelder Strabe just before the turn to Badenstedter Strabe. As the closest side street is Riechersstrabe, I suspect the station wil be called Riechersstrabe, but I am not certain. Smiley.toerist (talk) 10:39, 25 July 2024 (UTC)

Solved: https://en.mapy.cz › ?source=pubt&id=24659906.Smiley.toerist (talk) 10:46, 25 July 2024 (UTC)

TIFF to JPG potential loss of quality

I just collected some high quality scans of some Ilford HP5 135 monochrome negatives, shot at 400 ASA, and developed by a professional lab some thirty years back. They are now in TIFF format. So I duly ran a test file through convert from ImageMagick 6.9.11-60 on Ubuntu Linux. The file size shrunk from 74 MiB to 11 MiB — hence just 15% of the original. Should I be worried? Are their options I should apply when using this ImageMagick utility to keep the quality up? TIA. RobbieIanMorrison (talk) 12:39, 25 July 2024 (UTC)

Regardless of whether a solution to the problem mentioned can be found, you can also upload the TIFF scans directly (ideally uncompressed). --Túrelio (talk) 13:29, 25 July 2024 (UTC)

I would prefer to do that and "archive" the original scans on Wikimedia (these images are historically significant, shot in Prague during the Velvet Revolution of 1989). Thanks for your answer Túrelio. RobbieIanMorrison (talk) 13:54, 25 July 2024 (UTC)

Just noting that file --brief reports (edited output): TIFF image data, height=4134, compression=none width=6218. So uncompressed. And the converted JPG is also 6218x4134 and doubtless very compressed. RobbieIanMorrison (talk) 15:24, 25 July 2024 (UTC)

Further question: If I upload the file scan.tif, then I assume that any modifications that I upload must also be in TIFF format. In addition: GIMP prompts to convert from Adobe RGB (1998) to GIMP built-in sRGB and I guess I should reject this suggestion (these images are monochrome so I am really asking for future reference). TIA RobbieIanMorrison (talk) 16:09, 25 July 2024 (UTC)

Complete map of the moon (luna)

Does the NASA actually offer a complete map or a dataset that covers the moon's whole surface (or at least a big part of it) in form of a webpage or online service? Might be interesting to depict mariae, craters etc. :) --PantheraLeo1359531 😺 (talk) 18:19, 25 July 2024 (UTC)