Commons:Village pump/Archive/2026/06

Wiki Indaba 2026 – Scholarships & Program Call now open | Abidjan, November 13–15

Dear Wikimedians,

The call for applications for scholarships and the program of Wiki Indaba 2026 is now open.

This year, the conference will be held in Abidjan, Côte d’Ivoire, from November 13 to 15, 2026, under the theme “Africa’s Future: Knowledge Equity and Innovation”.

Wiki Indaba is the premier gathering of Wikimedians from the African continent and the diaspora. If you have a project, an experience, or an idea to share with the community, now is the time to submit your proposal.

Two applications are available: • Scholarship application → bit.ly/INDABA26_SCHOLARSHIP • Program proposal → bit.ly/INDABA26_PROGRAM

⏳ Deadline: June 30, 2026 at 11:59 PM GMT (for both)

We look forward to welcoming you to Abidjan! Abiba Pauline (talk) 21:36, 1 June 2026 (UTC)

1 petabyte of freely usable media files

Commons is close to 1 petabyte. Currently, the Special:MediaStatistics reads: "Total file size for all 142,471,025 files: 1,085,665,611,155,968 bytes (987.41 TB)". Congrats. emijrp (talk) 16:52, 1 June 2026 (UTC)

• Let me add a hint: You talk about pebibytes. A pebibyte is equal to 2⁴⁰ bytes or approx. 1.099 petabytes and a petabyte are 1,000 terabytes :) --PantheraLeo1359531 😺 (talk) 17:04, 1 June 2026 (UTC)

  Not really. I meant 1024 TB = 1 PB, thats why I said "is close to". We are not there yet, but will soon. Regards. emijrp (talk) 17:10, 1 June 2026 (UTC)

  That would be 1024 TiB = 1 PiB ;). Prefixes like k, M, G, T and P are SI prefixes with base 1000. The IEC prefixes like ki, Mi, Gi, Ti and Pi are IEC prefixes with base 1024. We cannot confuse the prefixes where a terabyte would be 1024 gigabytes but a teragram would be 1000 gigagram. 🙃 --PantheraLeo1359531 😺 (talk) 18:41, 1 June 2026 (UTC)

  Apparently Special:MediaStatistics has no problem with it, it uses TB, though you can report a bug if you want. emijrp (talk) 18:57, 1 June 2026 (UTC)

It would be great if Arch Mission Foundation could use several of these disks to store that petabyte in this facility, as they did with (the then current content of) English Wikipedia in 2024. Not because I fear a big apocalyptic event happening anytime soon, but as a last safeguard against other things that can (and, sadly, often do) happen. MGeog2022 (talk) 12:05, 3 June 2026 (UTC)

The demands for digital storage will increase fast. So this would be a good thing --PantheraLeo1359531 😺 (talk) 16:04, 4 June 2026 (UTC)

Less than 4000 media needing categories as of 2021

By now, less than 4000 media needing categories as of 2021, but we got stuck at the letter N and still have to categorize some difficult-to-categorise files in foreign languages. Do you want to contribute, to categorize the reminder, please? NearEMPTiness (talk) 05:11, 2 June 2026 (UTC)

The categorisation of the all media needing categories as of 2021 is nearing completion due to the work of @User:Stefan Kühn, @User:Prototyperspective, @User:Gbawden, @User:ProtoplasmaKid, @User:Krok6kola, @User:Jochen Burghardt and many other non-disclosed contributors. Now, we need to team-up once again, to categorize the media described in foreign languages, please. Should we then tackle all media needing categories as of 2022 or take a break? NearEMPTiness (talk) 04:11, 5 June 2026 (UTC)

I think we’re on the right track. If you look at the statistics, we’ve tagged about 120,000 files in four months. So we’ve reduced the large pile of uncategorized files by an average of about 7,000 files per week. If we all keep this up and don’t lose sight of the goal, we should have only a few files left by the summer of 2027. @NearEMPTiness: Thanks for always being so active in promoting this work. --sk (talk) 07:56, 5 June 2026 (UTC)

@NearEMPTiness (ping) --PantheraLeo1359531 😺 (talk) 15:11, 5 June 2026 (UTC)

We slowly reached the letter S. More help is required, please, to keep the ball rolling. NearEMPTiness (talk) 00:51, 6 June 2026 (UTC)

• I just handled a couple of images with Persian names (and Iranian subjects) but that had been held in Uncategorized media with description in Arabic language. There are probably more, because the scripts are nearly indistinguishable to non-readers; just a heads-up to any FA speakers to have a look in that category as well. (And possibly vice versa, not to mention the other languages with similar writing.)—Odysseus1479 (talk) 02:52, 11 June 2026 (UTC)

Resolved: All media of 2021 have been categorized. Thank you very much for your contributions. NearEMPTiness (talk) 05:28, 11 June 2026 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. NearEMPTiness (talk) 05:28, 11 June 2026 (UTC)

Key for categories of Stolpersteine in Milan, Venice and probably in other cities too

Is it really useful to sort the Stolpersteine by the victim's last name? Because in my opionion it's a mess to leave some stumbling blocks sorted by the victim's last name while others (for example, photos with multiple Stolpersteine) aren't. Andrek02 (talk) 15:21, 6 June 2026 (UTC)

If it can be done consistently, it is presumably useful to bring multiple images of the same stone near each other, and also stones for multiple members of the same family. - Jmabel ! talk 22:28, 6 June 2026 (UTC)

Accidentally overwrote a crop

At File:Lorenzo and Henrietta Music.jpg, I was trying to crop the image and accidentally overwrote instead of uploading the cropped version separately. Can someone please fix this? TenPoundHammer (talk) 15:49, 6 June 2026 (UTC)

@TenPoundHammer: That's not difficult. Simply revert to the starting point (I did this already) and redo the crop. Please mind using the CropTool's Lossless mode to avoid a en:generation loss. Regards, Grand-Duc (talk) 16:23, 6 June 2026 (UTC)

Clarifying the closing time zone for Photo Challenge submissions and voting

I would like to raise a question regarding the closing time zone used for the Photo Challenge.

Recently, while handling the vote counting process, I noticed an inconsistency between the actual submission deadline and the wording currently used in the challenge pages. In practice, the submission period appears to close at 00:00 AoE on the 1st day of each month. However, the written description in recent months has stated the deadline as 00:00 UTC on the 1st day of each month.

There was also previous advice from experienced Wikimedians suggesting that the voting period should preferably end using AoE time, as this gives contributors around the world a more inclusive and predictable deadline. Nevertheless, the wording used in recent months has mainly referred to UTC.

This creates a potential ambiguity: contributors may understand the deadline differently depending on whether they rely on the actual timing, the page wording, or past practice.

I would therefore like to ask the community to clarify which time zone should be used as the standard closing time for the Photo Challenge:

• Option A: Use 00:00 AoE on the 1st day of each month as the standard closing time.
• Option B: Use 00:00 UTC on the 1st day of each month as the standard closing time.

My own view is that whichever option is chosen, the most important point is that the submission and voting pages should use consistent wording, and that the actual closing mechanism should match the stated deadline. This would help avoid confusion for participants and make future vote counting easier to manage.

Comments and suggestions are welcome, especially from users who have previously helped maintain or close the Photo Challenge pages. This is Taiwania Justo speaking (Reception Room) 13:29, 2 June 2026 (UTC)

how about for simplicity sake just set the deadline to UTC 00:00 2nd of each month? so every contest is always open exactly from 00:00 1st day of current month to 00:00 2nd day of next month UTC? RoyZuo (talk) 15:04, 3 June 2026 (UTC)

Thank you, I think this is a reasonable simplification, and it would certainly be easier to describe and implement than using AoE explicitly.

However, I think the effect is not exactly the same as AoE. Setting the deadline to 00:00 UTC on the 2nd would give some regions additional time beyond the end of the 1st in their local time zone, while AoE is specifically intended to close the contest only after the last time zone has passed the deadline.

Therefore, I would still slightly prefer using AoE if the goal is to handle global time zones fairly. That said, if the community prefers a simpler fixed UTC-based rule, then 00:00 UTC on the 2nd could be a workable compromise. The most important point is that the wording and the actual closing mechanism should be consistent. This is Taiwania Justo speaking (Reception Room) 04:08, 5 June 2026 (UTC)

everything utc would be actually fairer since everyone has the exact same period of time (1 month + 1 day) to submit. RoyZuo (talk) 08:11, 5 June 2026 (UTC)

 Support I don't know as I have an especially strong opinion as long as it's clear, but UTC is the de facto Internet Time Zone (and is generally when things on the front page of Wikimedia sites update), and being open from 0:00 UTC on the 1st day to 0:00 UTC on the 2nd day of the following month is unambiguous and easy to understand. — PeterCooperJr (talk) 20:10, 5 June 2026 (UTC)

@Jarekt: Since you have been involved in maintaining the Photo Challenge, I would appreciate your opinion on this issue, especially on the proposed UTC-based compromise. This is Taiwania Justo speaking (Reception Room) 05:59, 6 June 2026 (UTC)

User:Taiwania Justo, I do not have much of an opinion, I only know that original approach of advertising and enforcing 00:00 UTC resulted with a lot of unhappiness from people (mostly in the US) who think that deadline is at midnight but forget that it is midnight in London and they missed the deadline. I was rejecting large number of entries from last minute submitters and they were not happy. Quietly moving the real deadline by 12 hours, removed most late entries. So in Template:Photo challenge rules I would replace UTC with AoE. --Jarekt (talk) 14:47, 6 June 2026 (UTC)

Hmmm, here's my opinion: If the deadline is AoE, the period will be 1 month + 12 hours (current AoE = UTC-12), and 2nd day of the month UTC will be 1 month + 1 day. These options are ok for me. This is Taiwania Justo speaking (Reception Room) 11:18, 7 June 2026 (UTC)

Can Template:NoFoP-non-buildings-category be made?

In Wikimedia Commons, indication of FoP status templates are exist for buildings and public arts categories.

• {{FoP-category}}: For categories of buildings and public arts from a public space in a country that provides Wikimedia Commons-acceptable freedom of panorama
• {{FoP-buildings-category}}: For categories of buildings from a public space in a country that provides Wikimedia Commons-acceptable freedom of panorama for for architectural works only
• {{NoFoP-category}}: For categories of buildings and public arts from a public space in a country that does not provide Wikimedia Commons-acceptable freedom of panorama

After looking at these three templates, I suggest a template, {{NoFoP-non-buildings-category}}.

This is for categories of public arts from a public space in a country that does not provide Wikimedia Commons-acceptable freedom of panorama except for architectural work. (For example, Japan, United States, Finland, etc.)

And, this is intended to integrate {{NoFoP-Japan}}, {{NoFoP-US}}, {{NoFoP-Denmark}}, {{NoFoP-Finland}}, etc.

However, these countries have different criteria for distinguishing between works of arts and buildings.

For example, in Japan, if the exterior of a building, such as the Tower of the Sun, is treated as a work of art, it is treated as such. On the other hand, in the United States, works of art that are included as part of a building and treated as components of the building (e.g., if a column is shaped like a statue) are allowed on Wikimedia Commons.

How about {{NoFoP-non-buildings-category}}? --Ox1997cow (talk) 13:54, 6 June 2026 (UTC)

 Support but rename to something more professional. Suggested {{NoFoP-public art-category}}. Essentially, in all countries that only grant Commons-suitable FoP for images of architecture, almost all kinds of public art are not freely usable in photos, be it sculptures, murals, frescoes, paintings, and graffiti. My suggested wording:

This is a category of a copyrighted artistic work from a public space in a country that only provides Wikimedia Commons-acceptable freedom of panorama to images of architecture and not works of art in public spaces. Please do not upload more photographs or videos of such works, unless their presence is incidental or trivial to the overall image. If the work enters the public domain, please remove this template.

This should also mean redirecting all redundant template headers to this, such as {{NoFoP-US}} and {{NoFoP-Japan}}, and {{NoFoP-Denmark}}.

There is no need to enumerate the names of the countries (I think it's eight) with such FoP rules: Denmark, Finland, Japan, Malawi, Norway, Russia, Taiwan, and the United States. JWilz12345 (Talk|Contributions) 01:27, 7 June 2026 (UTC)

Then, how about {{FoP-buildings-category}} be renamed {{FoP-architecture-category}}? This will resolve the confusion with {{FOP-buildings-category warning}}. Ox1997cow (talk) 03:41, 7 June 2026 (UTC)

No need to rename that. "If it ain't broke, don't fix it," as a popular saying goes. There is no confusion. FoP-buildings-category suits the categories of modern buildings from those eight countries, while the template with warning suits the general categories of countries with no complete FoP (e.g. Azerbaijan and Ukraine, like "Buildings in Baku" or "Churches in Kyiv"). There are no issues in usage of these two as far as I know. JWilz12345 (Talk|Contributions) 04:23, 7 June 2026 (UTC)

Since the names of the templates are similar({{FoP-buildings-category}} and {{FOP-buildings-category warning}}), I thought about changing the name. Anyway, I will make {{NoFoP-public art-category}}. Ox1997cow (talk) 05:02, 7 June 2026 (UTC)

There are other types of architecture than buildings too, like bridges. Nakonana (talk) 13:23, 7 June 2026 (UTC)

@Nakonana@Ox1997cow I'd support the renaming. It appears in Japan, bridges are works of architecture, not just utilitarian engineering works. See this source used on COM:FOP Japan. JWilz12345 (Talk|Contributions) 14:50, 7 June 2026 (UTC)

What is it? Then, what is correct template name and contents of template? Ox1997cow (talk) 16:12, 7 June 2026 (UTC)

Just a simple renaming, to the category name you are proposing. Nothing else. JWilz12345 (Talk|Contributions) 03:18, 8 June 2026 (UTC)

I made {{NoFoP-public art-category}}. Then, When it integrate {{NoFoP-Japan}}, {{NoFoP-US}}, {{NoFoP-Denmark}}, {{NoFoP-Finland}}, etc? Ox1997cow (talk) 11:06, 8 June 2026 (UTC)

akg image

Anyone signed up with akg images? I'd like to add this 17th century PD-Art image to Commons, but you need to be signed up to akg to download the full resolution (2242 × 3364 px; 21.6 MB). Thanks! - MPF (talk) 12:17, 8 June 2026 (UTC)

@MPF: seems like it should be part of Category:Mughal album (muraqqa) (Louvre OA 3619). The Louvre has an alternative scan with a slightly different colour balance at https://collections.louvre.fr/en/ark:/53355/cl010371364 (5th image). --HyperGaruda (talk) 20:53, 8 June 2026 (UTC)

@HyperGaruda excellent, thanks! - MPF (talk) 21:21, 8 June 2026 (UTC)

@HyperGaruda added now as File:Perroquet rouge 1600-1615.jpg, though the Louvre source is much lower resolution than the akg copy (so if anyone wants to upload the akg copy, either on top or as a separate file . . .) - MPF (talk) 23:32, 8 June 2026 (UTC)

Court Order Concerning Commons Image Related to the 2026 Onikişubat School Shooting

Dear Community Members,

We write to you on behalf of the Legal Department of the Wikimedia Foundation regarding certain developments in Turkey relating to an image currently hosted on Wikimedia Commons concerning the 2026 Onikişubat school shooting.

On April 29, 2026, the Wikimedia Foundation was informed of a takedown order by the Muğla 2nd Criminal Judgeship of Peace, via the Turkish Information and Communication Technologies Authority. The Foundation was directed to take down an image titled "İsa Aras Mersinli, perpetrator of the 2026 Onikişubat school shooting", from Wikimedia Commons. The image is a blurred photograph, sourced from X/Twitter, which - according to its uploader - appears to show İsa Aras Mersinli, the perpetrator of a school shooting that occurred in the Onikişubat district of Kahramanmaraş Province on April 15, 2026. We understand that the image was nominated for deletion on April 15, 2026, and on May 8, 2026, the discussion was closed with a decision to retain the image. The user who closed that discussion concluded  that the image was educationally valuable and did not violate any of the community's applicable policies, including the COM:DIGNITY and the Identification guidelines.

The Foundation took note of the deletion discussion, and we also reached out to a member of the Volunteer Response Team for input. On May 12, 2026, the Foundation filed an appeal before the Higher Court Muğla 1st Criminal Judgeship of Peace. That appeal was subsequently rejected.

As we explore our limited legal options at this stage, we are notifying the community of these developments for two reasons:

• First, to keep you informed: we want to ensure that the community is aware of this development, and what has been done so far by the Foundation.
• Second, to prompt further discussions: we know that the deletion discussion received relatively limited participation, divided opinions, and covered issues not related to the Order (such as the intellectual property rights of CCTV owners). Other community members may have been unaware, and now may feel motivated to have their say. Whether the deletion discussion is reopened or not, your views on the importance of this particular file to the projects can inform our own strategy. Note in particular that other media hosted on Commons is not subject to this Order, and Wikipedia was already preferring to use other photographs. You should also consider the possible consequences of noncompliance with such an order; for now, we will not publicly speculate, but we do want you to understand that what is said and done here could have consequences beyond this particular image.

While we appreciate the reasoning reflected in the late April/early May's deletion discussion, there is also some local context and sensitivities surrounding the image that are worth noting. The investigation into the incident remains ongoing. There are reasons to believe that it was a copycat crime inspired by past shootings. Significant amounts of disinformation, shooter-glorification and calls for further school attacks apparently circulated online. Under Turkish law (including Article 24 of the Turkish Civil Code), the display of graphic or traumatic images may raise concerns relating to personal rights, privacy, and dignity, depending on the circumstances.

In that context, the Radio and Television Supreme Council/RTÜK has issued a public statement concerning content related to the Onikişubat school shooting. In that statement, RTÜK advised that traumatic footage and content violating the privacy of victims, students, or their families should not be broadcast. RTÜK further emphasized the importance of relying on official statements to avoid misinformation and urged media outlets and publications to remain mindful of public sensitivities and the psychological well-being of children.

This Village Pump post is not an instruction or direction for any specific editorial action or outcome. The Foundation fully respects the independence of the Wikimedia community in editorial content-governance matters.

That said, the Order is addressed to Wikimedia, so the Foundation must make its own assessment of its legal obligations, litigation risk, and the broader interests of the Wikimedia projects and the community. Community decisions under the community's own content policies are an essential part of how the projects are governed, and help inform the Foundation's legal strategy. However, these determinations, by themselves, are not binding on the Foundation's assessment of the action(s) it may need to take in response to a court order.

Accordingly, depending on the legal options available and the Foundation's assessment of the risks involved, the Foundation may take appropriate action under the Terms of Use, including an Office Action, where necessary to safeguard the projects, the Foundation, and the Wikimedia community more broadly.

We believe that constructive engagement with the community will help reach a resolution that appropriately considers the educational value of the image as provided under, community governance principles, local legal risks, and the long-term interests of the Wikimedia projects. For reference, please also take a look at the Legal Department's earlier note titled "Educational use rationales for controversial content" (here).

Thanks, BChoo (WMF) (talk), on behalf of the Wikimedia Foundation's Legal Department 23:48, 6 June 2026 (UTC)

Sigh, we are really gonna end 2026 with Commons being censored by every major Western country in the world huh? Trade (talk) 04:04, 8 June 2026 (UTC)

@BChoo (WMF): Are you able to share the content of the takedown order, the WMF appeal, and/or the rejection of that appeal? Omphalographer (talk) 05:16, 8 June 2026 (UTC)

We recently had many cases they show, that we need better procedures when dealing with privacy related issues. I think we definitely need a kind of community committee to decide such cases. GPSLeo (talk) 05:52, 8 June 2026 (UTC)

I dont feel our user base is large enough to justify a community committee in the first place, let alone for such a narrow topic. It works on ENWP for obvious reasons Trade (talk) 06:06, 8 June 2026 (UTC)

The DR was reopened for a third time yesterday. Those interested in the legal and privacy related arguments being relayed by WMF Legal can give opinions there. In effect that does make a "kind of community committee".

See Commons:Deletion requests/File:İsa Aras Mersinli, perpetrator of the 2026 Onikişubat school shooting.png --Fæ (talk) 06:17, 8 June 2026 (UTC)

BTW, Category:COM:DIGNITY-related deletion requests seems a useful category to review when discussing privacy related cases, and this DR is in it. Where there is unreasonable invasion of privacy, Commons policies do and should respect these aspects of the law. Fæ (talk) 11:21, 9 June 2026 (UTC)

Maybe one could draw the community's attention to such privacy related DRs by making it a habit to post a thread on VP about the existence of such a DR. Nakonana (talk) 08:07, 8 June 2026 (UTC)

ZoomViewer tool not working

Posted on the talk page for the tool, but reposting here because it says that page isn't monitored much. The ZoomViewer tool has never worked for me on any image, regardless of the browser used. Even the examples on the help page do not work, the page gets stuck on the 'processing image' screen and never loads the image. Do others also have this problem? The tool would be very helpful in viewing large images that browsers are otherwise unable to handle. Surajr7 (talk) 22:17, 8 June 2026 (UTC)

I can confirm it also doesn't work for me either. It looks like the current listed maintainers are User:Tim Starling, User:Tacsipacsi and User:Dschwen. In addition to the main thing being broken, the iff endpoint is also giving an error. [1]. Bawolff (talk) 01:21, 9 June 2026 (UTC)

As I said on the talk page, it's likely that it was broken by administrator intervention on December 24, 2025, as an emergency action related to its enormous disk space usage. There was no log entry, but see this discussion from May-June 2025 for context. If it takes 6 months for someone to notice and report that the tool is fully broken, it's really hard for me to justify spending any more time on it. There are a lot of things I could work on that would be of value to users pretty much every day. Tim Starling (WMF) (talk) 03:05, 9 June 2026 (UTC)

Given Tim's comment, i guess we should remove the link to the tool from {{LargeImage}} Bawolff (talk) 04:36, 9 June 2026 (UTC)

Thank you for the reply Tim Starling (WMF). I agree that trying to fix the ZoomViewer tool is a waste of time, the button is sort of hidden and probably rarely used. With that said, I think a built-in zoom function is badly needed and would see a lot of use. For example, the featured articles en:The Garden of Earthly Delights and en:Las Meninas get about 50k views per month each. The lead images (both featured pictures) are extremely high quality, near giga-pixel images. However, few users will ever be able to appreciate these high quality images. They take forever to load in-browser — if they do at all – and few will want to download an over 200MB image. These thousands of high quality images that have high use across Wikimedia projects essentially sit there unused because they are inaccessible to most users. Thanks, Surajr7 (talk) 06:12, 9 June 2026 (UTC)

Ah, I see a zoom feature is already in development. In my opinion development of the feature should be prioritized since it would see a ton of use and greatly add to the accessibility of images. Thank you for all the work you guys do Surajr7 (talk) 06:15, 9 June 2026 (UTC)

You should not interpret that phab task as indicating that any sort of zoom feature of very large images is currently under active development. Bawolff (talk) 06:20, 9 June 2026 (UTC)

I see, sorry I am not technical person. Is there a way to request that development of the proposed feature become active? I am talking about a general zoom function for all images, not just for very large ones. Surajr7 (talk) 06:42, 9 June 2026 (UTC)

Meta:Community Wishlist i suppose. Bawolff (talk) 11:27, 9 June 2026 (UTC)

New userscript: Cat-WD-Linked

Hi. Just finished writing a userscript that adds a menu item "Category WD links" to the tools menu of category pages on Commons and Wikipedia. Clicking it checks which subcategories are linked to Wikidata and checks if those items have P910 or P301 claims. It can be found at wikidata:User:Infrastruktur/cat-wd-linked.js. If you have any feedback, either use my Wikidata talk page or ping me because I'm not active on Commons. Infrastruktur (talk) 06:46, 9 June 2026 (UTC)

Deployment of Legal and Safety Contacts Link in the Footer of Your Wiki

Hello community,

The Wikimedia Foundation has provided a single legal and safety contact page, to be linked in the footer of your wiki, to ensure access to accurate legal information. This is a regulatory requirement.

We have already rolled out links to English, German, Italian, Spanish Wikipedias and other wikis and we will deploy to your wiki soon.

Please read more on the project page and leave any comments in this thread or on the talk page. –– STei (WMF) (talk) 17:20, 9 June 2026 (UTC)

Good. Those have been terribly hard to find. - Jmabel ! talk 04:38, 11 June 2026 (UTC)

Request for speakers of Indian languages: which language is this video?

File:President Trump Participates in a Bilateral Meeting with the Prime Minister of the Republic of India.webm. Narendra Modi is a Gujarati, but my assumption is that he's speaking Hindi since this is for a broad audience. Can someone please confirm that it's Hindi and delete the HTML comment that I added or replace Category:Videos in Hindi with the correct language? Thanks/धन्यवाद. ―Justin (koavf)❤T☮C☺M☯ 20:02, 17 June 2026 (UTC)

Yes, it is Hindi. ङघिञ (talk) 09:24, 20 June 2026 (UTC)

Lovely. ―Justin (koavf)❤T☮C☺M☯ 10:05, 20 June 2026 (UTC)

This section was archived on a request by: ―Justin (koavf)❤T☮C☺M☯ 10:05, 20 June 2026 (UTC)

Wiktionary logo

I wanted to upload a Wiktionary logo I designed for Norfuk-Pitkern Wiktionary, but it is not letting me upload because 'It is a copy of File:WiktionaryEn.svg' when it is a file derived from it. Thanks, ङघिञ (talk) 09:27, 20 June 2026 (UTC)

Sorry, it uploaded, turns out I mistakenly was going to upload the original file. ङघिञ (talk) 09:40, 20 June 2026 (UTC)

This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:32, 20 June 2026 (UTC)

Is it worth running OCR on full newspaper pages?

Is it worth running OCR on full newspaper pages like: File:"Scenes Taken at Huge $2,000,000 Pier Fire" Evening Vanguard, January 7, 1924.jpg, or just hope someone in the future breaks it down into the individual news articles? The Library of Congress does entire pages but it is of limited usefulness. --RAN (talk) 16:14, 11 June 2026 (UTC)

That's something for Wikisource to care about. Bedivere (talk) 22:37, 12 June 2026 (UTC)

Here's a sample of what an OCR does with it, so probably not worth the effort as the output is so buggy.

ye

MONDAY,    J ANUARY:   1

ief Congratulated for
Coolnezs Under -
* Fire
Officer Mer of the’ Venice police |.
‘ce turmed in the alarm of the |
ean Park fire yesterday at 9:50 |
m. when he phoned.tc Captain {
go.at the station hore, news: of |
spreading disaster.
here was troubje on the police |
@phone atid Officer De Villa, of |
D motor¢ycle corps rushed to the |
@cpartment and got Engine |
. 2-cf Company. No. 1 away in|
16 to be first at the blaze.
oung McCauslang, son of Chief
Police H. H.  McCausland,  who |
at the station, sped cn the |
nds of putting in an emergency. :

for every officer cn the force
turn get.               -.
The first consideration of: the of-
rs and orders given by Captain
go were for the roping off of
» lines ‘to keep the sight secing
blic: out’ of the fighting zones.
vaptain. Lingo drew on his ex-
ience af September 1912, when
was chief of police of the Ven-
force’ to tackle the early
ases of the work at the fire. -

ief of Police H. H. McCaus- |
hd, whd w

If you want to research how it can be done, this was using pytesseract with an "automated page segmentation" setting, more info. Fæ (talk) 20:14, 14 June 2026 (UTC)

• It is imperfect, as is the OCR done by the Library of Congress at Chronicling America. I tend to find better OCR at Newspapers.com. Newspapers.com reran all their OCR recently using newer software. You can pick out a person's name in your example, and that just might be what someone is looking for. Otherwise the few thousand newspaper page images we already host, are just decorations. --RAN (talk) 22:21, 15 June 2026 (UTC)

Who can help to categorise the 22,000 media items from 2022?

In the category All media needing categories as of 2022 are approximatels 22,000 items that need to be categorised. In February 2025, there were still 80,000 – so we are making good progress. Experience shows that the final quarter is particularly difficult and requires not only knowledge of categorisation but also the ability to read foreign characters. Tips on this can be found in the WikiProject Minimum One Category. Who is able and willing to help with this, or has a good idea on how it can be done most effectively? --NearEMPTiness (talk) 07:03, 13 June 2026 (UTC)

While I appreciate the intention, I am not sure I fully agree with some of the results of the previous round. I noticed a lot of files moved from one pile of uncategorized mess to another pile of essentially uncategorized mess (now in two flavours: Category:Unidentified locations and Category:Unidentifiable locations). Fine if it is combined with some generic category to describe the subject, but not as the only category (e.g. File:DSC 0147 (35990764463).jpg could have at least gone into some building category if one does not know it is Category:Osaka Castle). --HyperGaruda (talk) 08:39, 13 June 2026 (UTC)

I agree, looking Category:Unidentifiable locations, I can clearly see some images literally has the locations in their filename. For example:

• File:Darhal Valley.jpg
• File:East Shore Park.jpg
• File:Gate D of banshankari metro.jpg
• File:Lohajung Village with snow in January.jpg

So, not sure why these are "unidentifiable", and not placed in the correct category in the first place. Thanks. Tvpuppy (talk) 09:54, 13 June 2026 (UTC)

Yes, the objective is, to put the files into the most appropriate category, not only into an unidentified category. However, even the latter is useful, for instance, when an expert is needed to identify animals or plants. NearEMPTiness (talk) 12:13, 13 June 2026 (UTC)

• Category:Unidentified men has the same problem, the person may be identified in the caption or the image title, and is just missing a category for a person. --RAN (talk) 22:25, 15 June 2026 (UTC)

Flat lists

Do we have a category that contains all the flat-list categories? RAN (talk) 15:39, 14 June 2026 (UTC)

Sorry if this seems pedantic or rude, but I'm not sure how to word this. Can't you easily answer your own question by going to a flat category (e.g. Category:Surnames (flat list)) and seeing yourself that it is in Category:Flat categories? Is there something that I'm missing? ―Justin (koavf)❤T☮C☺M☯ 15:41, 14 June 2026 (UTC)

• Probably because we call the concept "flat lists" and we call the categories "Category:Flat categories". Solved with a new and simple redirect, Category:Flat lists redirecting to Category:Flat categories. --RAN (talk) 21:00, 15 June 2026 (UTC)

Which license to use by conferences?

I participated to an EPF conference and the organisers make the pictures taken during the conference available free of use.

Quote: SwissTransfer link with pictures taken by our photographers. You are free to use these photographs in any external communication. This link is valid for one month. :End Quote

https://www.epf.eu/wp/epf-confereepf-conference-2026-advancing-sustainable-passenger-mobility-across-europe/

Wich license should I use?

PS: There is Category:European Passengers' Federation (EPF) (my own pictures in past conferences)

Smiley.toerist (talk) 09:31, 10 June 2026 (UTC)

If someone is bold, they could say that this quote authorisation amounts to {{Copyrighted free use}}. But we should apply COM:PRP, which makes that statement from whoever insufficient for our purposes. It would be better if you could get a clear license name, maybe a statement that the media are made available under e.g. the CC-By-SA 4.0. I would actually refrain from a Commons upload for now. Regards, Grand-Duc (talk) 10:50, 10 June 2026 (UTC)

I am a member of the organisation wich organized this conference and know most of organizers personaly, so it would be no problem to confirm the authorisation. At the conference itself the policy about the availibility of the presentation slides and pictures taken was make public. There are lots of pictures of the speakers/presentations. Most of the speaker names are in the conference agenda, but if their is doubt who is in the picture I can ask.Smiley.toerist (talk) 09:39, 11 June 2026 (UTC)

@Smiley.toerist: you will have to make sure that the conference organisers actually have the intellectual property rights that the photographers own at first when making their images. They can be transferred, but that transfer must be documented, in writing. Furthermore, this rights transfer must allow for a free license. Ideally, any conference photographer did transfer "all economic exploitation rights" (or made a rights transfer with a wording of similar or broader meaning) to the conference organisation. That way, it's within the purview of you and your colleagues to grant a license (as the photographers did transfer that right beforehand). Regards, Grand-Duc (talk) 14:34, 11 June 2026 (UTC)

Its not our business to investigate if the internal paperwork of the organisation is correct. The photographers where not professionals, but members who where tasked to take pictures of the event, for use by the organiser. So wil ask the organiser to confirm a cc-by-sa-4.0 license, wich I will be using.Smiley.toerist (talk) 12:14, 12 June 2026 (UTC)

Per C:PCP, it is our business. The conference took place in Maastricht so Dutch copyright law ("auteursrecht") applies and that is pretty straightforward: Rights stay with the author unless it's explicitly transferred. You have to provide proof that's the case if you have the organizers provide the license. Probably better to have the individual photographers provide a license for the photos they took. Multichill (talk) 19:34, 12 June 2026 (UTC)

We do accept the GLAM claims that what they released to us, is public domain. (Unless we have evidence it is not). And if an organisation claims its pictures are free to use, we dont accept it. We are splitting hairs now and being more catholic than the pope.Smiley.toerist (talk) 22:01, 12 June 2026 (UTC)

GLAM institutions are (often) used to deal with intellectual property rights and have (often) some expertise in it. This cannot be reliably surmised for some associations organising conferences (unless it's e.g. a conference by attorneys in IP law). Regards, Grand-Duc (talk) 22:18, 12 June 2026 (UTC)

The law does not apply automaticaly for employees or volonteers working for an organisation. If people having a working relationship (employment) with the organisation get an assignment to take pictures for the organsation, the organisation gets the full authorship rigths, unless otherwise specified.Smiley.toerist (talk) 11:45, 14 June 2026 (UTC)

@Smiley.toerist: for employees or contractors that varies by country, and I'm not offhand aware of any country where volunteering for an organization would automatically assign them your copyrights. It certainly does not in the U.S. - Jmabel ! talk 22:15, 14 June 2026 (UTC)

In practice, volunteers and employees, will be wel advised to mention any restrictions, payments etc on their pictures, before they take the pictures. If there are limitations, the employer wil ask somebody else to do the work. If they demand their legal rigths afterwards, they wil jeopardise their work relationships with their employers. So these rigths are more theoretical. In practice most of these things are done informaly. Professional photographers wil make their conditions clear before any fotosession.Smiley.toerist (talk) 11:01, 16 June 2026 (UTC)

And, in practice, if an organization wishes to obtain copyrights in a situation like this, they would also do well to have contract terms to that effect. I've done a moderate amount of photography (in the U.S.) as a contractor in situations like this. I can't remember ever having to sign over copyrights, though I've certainly signed over very liberal usage rights, even sometimes including that I do not have to be credited on use by the organization itself. - Jmabel ! talk 18:28, 16 June 2026 (UTC)

Dashed lines in GEOJSON pages?

Is it possible to add dashed lines to a GEOJSON map data page? If it is possible, how? If it isn't possible, how could the feature be implemented? —TheGinger68 ↗ 20:38, 14 June 2026 (UTC)

Styling in these maps are defined in the simple style spec, and there’s no provision therein for dashed lines. Opening an issue on that GitHub page might get the right people to start thinking about it, but I’m not the one to be promising anything on that front. BMACS1002 (talk) 04:43, 16 June 2026 (UTC)

It’s been an open feature request for a long time. I wouldn’t be surprised if another existing implementation of the specification implements a dash pattern option unilaterally though. Minh Nguyễn ^💬 04:58, 16 June 2026 (UTC)

Colors of File:Flag of Russia (1991–1993).svg

Hello. Before reading the rest of this, I recommend that you take a look at the file talk. Three years ago, there was debate as to the shades of blue and red used for the Russian flag. This began a months long edit war in which for months the file was overwritten over and over again without much constructive discussion. An attempt was made on the talk page (the section which I linked to), but in my opinion it did not come to a constructive end: it never ended with any clear consensus.

Firstly, I would like to iterate the points made by each side. I will be quoting from these users directly or paraphrasing them. For the ease of discussion, I will be referring to the side which supports the status quo as A.S. (Azure-Scarlet, after the translation of the shades of the flag described in the official law), and B.R. (Blue-Red, after the alternate proposed shades). I will be inviting all users from the previous discussion to discuss here as well.

A.S.
User:Rustycaddy17 started the linked discussion on the talk page by emphasizing the wording used by the official law. Quote: "The official law used the word 'Azure' in the description, which is a lighter shade of blue, similar to cyan. In 1992, there was a special constitutional commission to work on the new constitution... [t]here were specific quests to the commission to specify the definition of the State Flag since it was completely different from the Tsarist definition of the Tri-color flag... [they] decided on changing the definition [of the colors] to the Tsarist definition by removing the color 'Azure' and replacing ti with the color 'Blue'." He cited a source: [2], *On the history of the Creation of the Constitution of the Russian Federation*. He emphasized this part as well: "The colors specified in the law at the time were the official colors, period." (his own formatting) Finally, he noted the lack of official Pantone or RGB codes at the time, which is why there is inconsistency between shades as can be seen in photographs. He emphasizes that what matters is the law.

User:Illegitimate Barrister commented on the matter as well. Before he did, the discussion had started to move towards archived images: two of them were photographs of the flag waving atop the Kremlin Presidium building. in November 1991 with shades of blue and red closer to the 'Azure' and 'Scarlet' colors described by the law, which can be seen [3] [4] here. Barrister said that he believed the two mentioned photographs should be the most authoritative, quote: "I'd go with the one over the Kremlin since it being on the most important flagpole flying over the most important building in the country seems to imply it is more 'official' than the others.", later writing in response to criticism, "No. The most important flagpole in the country trumps some random room in some obscure office building."

The last argument made by the A.S. side before the discussion died was that the ensign of the Russian navy had originally used a lighter shade of blue from 1992 until 2000. The reason why was the specifics of the shade: the presidential decree which established the usage of the flag [5] specified the shade of blue as голубо́й, or Azure. He says that he does not believe that the intent of the authors of the flag law was to use 'poetic words' because *"Heraldry is a separate science to Vexillology."* In his eyes therefore, it was not a mistake or mistranslation when the authors defined azure and scarlet: it was intentional, and the shades should reflect that.
Summary: Proponents emphasize language of official law, photographs showing the usage of azure and scarlet atop the Kremlin, and the inconsistency in shades as proof that the 'standard' as set by law should be used.

---

B.R.
User:NorthTension replied to the original post. A frequent source cited was this Youtube video made by Pesetz titled YELTSIN'S FLAG OF THE RUSSIAN FEDERATION (which never existed) / How was the white-azure-scarlet flag adopted and why was it abolished?. [6] I suggest that everybody who comments on this to watch that video first, regardless of whether or not you believe it to be a good source or not: it (basically) summarizes up the arguments made by the B.R. side and is regardless a needed source to understand their argument.

Additional sources cited were Victor Lomantsov's article on the national flag of Russia [7]. Victor Lomantsov serves as editorial staff on *Flags of the World* and also runs *Vexillographia*, which is now the official webpage of the Russian Center of Vexillology and Heraldry. Victor said on the FOTW entry for the 1993-1993 flag: "[While the] official text (1991-1993) [says] white-azure-scarlet, [the flag was really]... white-blue-red. [The] authors of [the] flag-decision of 1991 were not vexillologists. They didn't [know] vexillological terminology. They [thought] that 'white', 'blue' and 'red' are very 'ordinary' words and they decided to use more 'refined' words: 'azure' and 'scarlet'. (For example, in heraldry, 'ordinary' words are not used. Instead heraldists say 'gules', 'azure', 'vert' instead of 'red', 'blue' and 'green'...) In 1993 this terminological vagueness was corrected." [8] I am sorry for having reworded that so much, but there was broken English in place-to-place and I simply tried my best to reconstruct a more clear meaning. You can see the source for his original wording. It should be noted that the citing of Lomantsov was the source of Rusty bringing up the ensign of the Russian navy as proof that the makers of the flag law knew what they meant when they said 'azure' and 'scarlet'.

To close this off, they also noted that as heraldry was abolished by the Soviets and that it became a defunct practice during Soviet rule, that the makers of the flag law were not referencing heraldic terms, but were intentionally using those terms in a vexillological context. I would like to say that this is not true. While traditional heraldry was abolished by the Soviets, it is inaccurate to say that heraldry as a whole was abolished; they invented a 'socialist heraldry' rather than get rid of it entirely. I would like to cite the Soviet's regulation of the State Emblem (31 Mar 1980) as proof that the Soviets still understood heraldic colors. I'd also like to discuss this later.
Summary: Proponents emphasize the alleged lack of knowledge by the original flag law makers, and that photographs of the flag from the time indicate a bias towards the original 'blue and red', not 'azure and scarlet'.

---

Photographs
If we cannot agree on whether the original flag law should be treated as correct or not, then we have another way of settling this: how many photographs from the time show the flag with shades closer to A.S., and how many show it with shades closer to B.R.? I have scoured commons, and the internet, for every single possible photograph of the flag being used in an OFFICIAL context (so no protests or whatever, just official government use). Okay, not literally, but still. I'm simply reporting what I managed to find, and I tried to list as many images as possible here. If you find more, link them PLEASE.

This is where my search basically hit a dead end. I could absolutely find more, but I'm stuck on where else to look. If you have any other photographs of the Russian flag being used in an official context, link them, I beg you. If you disagree with my shade interpretation of this photograph or that photograph, say something! Bring it up! The more we understand each-others' arguments and the more sources we can cite, the better chance we have at reaching a consensus. I did not search with any bias toward one shade or the other. My only bias was in restricting it to official usage. The fact that A-S doesn't appear as much as B-R in the photographs I've linked doesn't automatically mean that A-S wasn't used more prominently: it's just that from the corpus of images I've found, there are more which feature B-R. Like I said, if you have any more images, link them.

---

Personal Opinion
Firstly, semantics. The flag law did not, as a matter of fact, use голубо́й to describe the shade of blue. Instead, the two colors cited were Лазу́рь (Azure) and Алый (Scarlet). While 'Azure' is used as a translation for goluboj, it is more accurately translated as 'sky blue', which is only one of many tints that the rather broad definition Лазу́р gives. Azure in heraldry can mean all shades of blue (Синий) and sky blue (голубо́й). I assume that the reason why the two are confused is because the original Supreme Soviet proposal suggested голубо́й, but the actual law that amended the constitution did not. The fact that the RSFSR flag used light blue and 'crimson' (krasnaya) shows that the drafters of the amendment deliberately wanted to avoid the colors of the old flag: their usage of Azure and Scarlet was not a mistake: it was a deliberate, informed choice.

The first problem lies with the broadness of Lazur: in Russian, Lazur can be what we would translate as Azure; it can just as easily be a deeper shade of blue as well. The second problem is with Scarlet: the shade we currently use to represent scarlet on the flag, regardless of whether Azure-Scarlet stays or not, is completely wrong and is not scarlet. Scarlet is red-orange. Whatever is on there right now is not. I believe that the flag law cannot help us say for certain what shade of blue was intended to be used, only that it was supposed to be a shade of blue. All Russian flags from the period therefore are actually correct at the same time: there was no 'standardization' because the colors used can mean a whole hell of a lot of different things. What will help us is looking at records and seeing how more prominently one shade was used over the other.

My conclusion is this: If A-R wins out, then the flag should be immediately adjusted to fix the shade of red used in the flag: it is not currently scarlet. If B-R wins out, then it wins out. I don't care about anything besides the scarlet.

---

TL;DR: Which colors should we use? I have been writing this for 4 hours. I'm tired. TheodoresTomfooleries (talk) 01:41, 19 June 2026 (UTC)

As Ivan B-R my position is obvious, but I do also want to reiterate that my opinion is the result of a very well detailed and sourced video and one of the literal heads of Russian vexillology. I did not receive any actual counters to the sources I used with Rustycaddy even saying that the video "cherry-picked evidence" which it didn't, it had multiple photos and videos alongside multiple sources in the description and pretty plainly explained the situation. NorthTension (talk) 02:46, 19 June 2026 (UTC)

• File:Обложка Конституции РФ 1992.png
• File:Флаг над белым домом.jpg

File:Флаг из кабинета министра Ярошенко.jpg

• File:1992. Марка России 0010 hi.jpg
• File:Russia stamp 1992 № 58 ml.jpg
• Category:Banknotes of the Russian Federation, 1992
• Category:Banknotes of the Russian Federation, 1993
• File:Standard of the President of the Russian Federation (1991-1992).png
• File:Standard of the President of the Russian Federation (1992-1993).png
• File:Standard of the President of the Russian Federation (1993).png

Nakonana (talk) 20:40, 19 June 2026 (UTC)

I've added all of these except the presidential standards to the list. We don't want graphics; we want photographs or reproductions. Do we have any photographs of the presidential standard? TheodoresTomfooleries (talk) 21:33, 19 June 2026 (UTC)

I didn't spot any on Commons (for the time 1991–1993). Nakonana (talk) 21:40, 19 June 2026 (UTC)

Photo challenge April 2026 results

{{Commons:Photo challenge/2026 - April - Fair grounds/Winners}}
{{Commons:Photo challenge/2026 - April - Wooden bridges/Winners}}

Congratulations to @IM027, @BogTar201213, @F. Riedelio, @Nocomentapapun, @Jean-Marie Vugnon (2) and @Kmtextor. This is Taiwania Justo speaking (Reception Room) 15:56, 14 June 2026 (UTC)

Once again I have disabled display of the templated images, as the templates cause significant horizontal scrolling.

I thought this had already been resolved. We have ample means of displaying images without horizontal scrolling, not least <gallery>. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:36, 20 June 2026 (UTC)

SDC constraint for flickr

example File:" Fot.Andrew Skowron (47949298598).jpg.

published in (P1433)

The value for published in should not be one of the following: Flickr...

since such sdc has been written to a lot of files, to fix the constraint is either remove the constraint or change this sdc model, i guess. or just pretend we dont see this constraint... RoyZuo (talk) 20:07, 16 June 2026 (UTC)

 Comment, the constraint for Flickr was added by @Trade on 9 June 2026, with the explanation: "larger work that a given work was published in" Social media websites are not works.

I'm not familiar with this Wikidata property, but it sounds like perhaps the property was misapplied for the image. Thanks. Tvpuppy (talk) 20:21, 16 June 2026 (UTC)

The point where we have to argue whether or not Flickr is the same thing as a book or a magazine is the point where any semblance of logic went straight out of the window. Trade (talk) 15:22, 17 June 2026 (UTC)

I don't think anyone is arguing whether or not Flickr is the same thing as a book (obviously not). I think the important thing is to discuss what to do when the property has already been misapplied to many Flickr images already. Thanks. Tvpuppy (talk) 15:38, 17 June 2026 (UTC)

the problem is published in (P1433) is "larger work that a given work was published in, like a journal, a website, a collection, a book or a music album" so why certain websites should not be allowed?

unless there's a general consensus that this constraint is reasonable, it should not be added, especially since a data model has been made to use it for millions of files. RoyZuo (talk) 15:06, 20 June 2026 (UTC)

The "larger work" should be something which is generally considered to be a single collective work. The entirety of all files on Flickr are not such a work. Omphalographer (talk) 17:13, 20 June 2026 (UTC)

Duplicates or overwriting of scans at the Internet Archive.

• File:A dictionary of the English language- in which the words are deduced from their originals, and illustrated in their different significations by examples from the best writers - to which are (IA 0037263X1.nlm.nih.gov).pdf (edit|talk|history|links|watch|logs)
• File:Medical Heritage Library (IA 0037263X1.nlm.nih.gov).pdf (edit|talk|history|links|watch|logs)
• https://archive.org/details/0037263X1.nlm.nih.gov

Can anyone diagnose why these versions exist for the same book and unique IA number? If there's a mass pattern we might need to add cross references. Same resolution scans, but different PDF size. Fæ (talk) 15:13, 17 June 2026 (UTC)

This has not been solved as to the root cause, however on the presumption that something odd has changed on how IA is compressing the pdf versions, there is extra care being taken to avoid duplicate IA IDs. Fæ (talk) 07:22, 20 June 2026 (UTC)

Which Copyleft Licence is Suitable for an SVG?

Some of you might enjoy this blog post by User:Edent:

https://shkspr.mobi/blog/2026/06/which-copyleft-licence-is-suitable-for-an-svg/

Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:29, 20 June 2026 (UTC)

I have read this person's blog before and think it's interesting and instructive. I would disagree that an SVG file is a piece of software, as it's a document, just like any other XML document, which could be XHTML or MathML or an RSS feed, etc. What a particular program chooses to do with that document and how it interprets instructions in it is up to that program. His point about embedded scripts is certainly correct, but the same is true of HTML documents or PDFs: by this definition, what are clearly documents aren't documents or they cease to be documents when including scripts, which is pretty absurd to me. That said, it's an interesting perspective and one I respect; I think it's worth reading and considering for sure. ―Justin (koavf)❤T☮C☺M☯ 13:02, 20 June 2026 (UTC)

"Document" includes types of file with various possible ways to inject behaviours. In terms of expectations for threats, it makes sense to treat them as software. Though the focus was copyright, the way Terence describes SVG as something that creates images rather than being an image is useful framing for other formats, as the same can be said about HTML or wikicode which create text on a page. At this moment as script kiddies can talk to an AI to create exactly the right injected "code" to, say, invisibly change the way their essay might fudge AI detection tools, or an image on Commons might be listed by later search engines, it's a hot issue without easy solutions. Fæ (talk) 13:29, 20 June 2026 (UTC)

All of this is 0s and 1s and so any computer program could take this as instructions to execute some code somehow someday, so you are correct that when it comes to certain kind of threat modeling, documents that can include executable code or scripts are definitely a different thing than documents that can't, but to your point that the original discussion is about copyright and what kind applies, when someone makes an SVG file, that person is making a creative work. Even if it includes animation or dynamic interactive elements, it's still an attempt to make an image, so the kinds of protections that relate to it are/should be (in my non-legal scholar opinion) those of a creative work. It's hard to say where this would end if we treated documents as software: are macros the same thing? What about spreadsheets that have pivot tables? Also, not sure what your HTML comment was about LLMs. ―Justin (koavf)❤T☮C☺M☯ 13:48, 20 June 2026 (UTC)

you could also ask if the colour profiles in jpg files are software Bawolff (talk) 14:20, 20 June 2026 (UTC)

Or, to take it to the point of absurdity: are the LZ codes in a compressed PNG image a 'program'? They are, after all, a sequence of 'instructions' which are 'executed' to reconstruct the image.

Realistically: the GPL should not be applied to images, regardless of the file format. The license presumes that the subject of the license exists as textual "source code" which is compiled into "object code" before being executed on a computer. It is not at all clear how these terms would be applied to an image; even if one creatively interprets those terms (e.g. treating the SVG text as "source code" and a PNG rendering of it as "object code"), it's not at all clear what that means for reuse of the image. Omphalographer (talk) 21:42, 20 June 2026 (UTC)

if the point of the blog post is that software with source code should be GPL not cc-by-sa, then i think svgs should still be cc-by-sa. It is extremely rare that SVGs have a concept of source code separate from object code. GPL in general is kind of unclearly defined when it comes to interpreted languages that are typically sent to the client (e.g. is sending JS to the browser "distributing" the software). Bawolff (talk) 14:14, 20 June 2026 (UTC)

Yes, if you send a copy of the program to the user, it's distributing the software. I don't see what's ambiguous about that.--Prosfilaes (talk) 19:33, 22 June 2026 (UTC)

Template By colour

Hello, could the link to the category in template {{By colour}} be changed from Foo by color to Foo by colour. You end up with red links such as Category:Doors in England by color rather than Category:Doors in England by colour. To get the color variant template {{By color}} is available. Keith D (talk) 19:50, 20 June 2026 (UTC)

There is a problem here, but it would need to be solved by checking for existence of categories, not by fixing UK categories by breaking the analogous categories for the U.S., Canada, Australia, Ireland, France, Russia, etc. - Jmabel ! talk 02:42, 21 June 2026 (UTC)

It is just the link that is incorrect because it pipes "Foo by Colour" to a category "Foo by color". If you want the link to category "Foo by color" then you should be using template {{By color}} not {{By colour}}. Keith D (talk) 19:06, 22 June 2026 (UTC)

The "by colour" template is used on almost a thousand pages (the "by color" template is used on multiple thousands) and not all of them use British English spelling. The template fix is fairly straightforward, but I think the correct template should be applied first. Making the change now would be premature, as it could result in links breaking on potentially hundreds of pages. ReneeWrites (talk) 23:53, 22 June 2026 (UTC)

File renaming involving a change of a biological taxon

Apparently, COM:FR does not deal with cases where a picture of a plant or animal has a name that incorrectly refers to a particular taxon in the biological nomenclature. Of course, by itself, it is desirable to change the incorrect name into the correct one. However, sometimes the picture is already in use on one or more projects as an illustration for the incorrect taxon. Just changing the name of the file on Commons, followed by an bot renaming the file on the projects involved, leads to an awful result. In many cases the project still shows the wrong image, often with the original incorrect description below it. In fact, Commons itself can be among those projects, when the picture is used in the infobox of the incorrect category page or on a page showing a selection of images of the incorrect taxon.

In my view a reasonable solution would be an extension of the guideline COM:FR, requiring that cases where the use of an image to be renamed would become incorrect are solved (by changing or removing it) before the file name is changed. This could be done by anyone who feels competent to do so:

• the user making the request;
• any user who is willing to assist;
• the file renamer.

I have seen examples of all three possibilities and they seem all fine to me. What we should try to avoid are the cases where just a file name is changed, but the incorrect information on projects remains. Unfortunately, I have seen examples of those too. Would the solution I suggest be acceptable? --MarcoSwart (talk) 21:13, 20 June 2026 (UTC)

I'm not sure why this is any different from the situation where any other factual error is corrected in a filename, where the factual error might be relevant to how the file is used. And I don't see why renaming should specifically be the last step in the process of fixing a factual error. - Jmabel ! talk 02:47, 21 June 2026 (UTC)

Criterion 3 on COM:FR mentions that misidentified biological taxa are an acceptable reason to rename files. As for whose responsibility it is to correct misinformation on other projects, that is harder to say, since such a guideline would apply outside of Commons, which is not usually something Commons policies and guidelines address. --ReneeWrites (talk) 23:34, 22 June 2026 (UTC)

This is really obviously an AI-enhanced image, right?

File:Peter Sotos NYC.jpg I don't think it could be more obvious. Yet at the deletion request (Commons:Deletion requests/File:Peter Sotos NYC.jpg) the uploader denies it. I want to get a second opinion on whether this is an AI image. PARAKANYAA (talk) 12:52, 22 June 2026 (UTC)

I'd say it certainly looks edited, there's a cutout style to it as if the person has been pasted into a different background. Aesthetically it looks sharply upscaled at smaller sizes but blurry at larger ones, so I'd guess there was some AI in the mix.

The uploader says I took this picture myself in 2009 with a camera. I took a photo of that [physical print] picture with an iPad in 2026., so the issue probably lies in that unusual extra step of taking a photo of a photo. Perhaps the iPad camera was trying to enhance what it thought it was looking at (if it had two camera lenses and was trying to blur out "the background" as if it was taking a photo of a person in real life?), or the user pressed a button for "enhance this image" without thinking of that as involving any AI. Belbury (talk) 13:30, 22 June 2026 (UTC)

This image does not appear to have been generated or substantially processed by AI image models. As Belbury mentioned, it may have gone through some processing by the iPad's camera, or during the upscaling process, but there doesn't appear to have been any more extensive modification. A proper scan of the photo (or a photo of it taken with a better camera) would certainly be preferable. Omphalographer (talk) 16:26, 22 June 2026 (UTC)

The face is very clearly AI-enhanced, and as Belbury said it "looks sharply upscaled at smaller sizes but blurry at larger ones, so I'd guess there was some AI in the mix", post processing does not get you whatever that is. PARAKANYAA (talk) 16:48, 22 June 2026 (UTC)

• There are plenty of digital processing artefacts that could explain this without it necessarily being 'AI'. Nor does that even matter: We don't have any blanket ban on AI use, for either generation or for image processing.

If you look at the policies we do have (such as COM:AIIP), what is this in breach of? It's never going to get a 'quality image' award, but does that change anything at a DR? Andy Dingley (talk) 17:20, 22 June 2026 (UTC)

Might be in breach of failing to indicate retouching. - Jmabel ! talk 19:34, 22 June 2026 (UTC)

Jmabel, the lopsided nose (which, based on other photos on the internet, is not what he looks like) may be incompatible with COM:PEOPLE#Defamation? - Alexis Jazz ^{ping plz} 20:02, 22 June 2026 (UTC)

Does not appear to be AI, but obviously tampered with. For one, his nose is lopsided. The background has almost certainly been swapped out, characteristics of a photo taken of a photo do not extend to the background. It looks like a botched photoshop job. - Alexis Jazz ^{ping plz} 19:04, 22 June 2026 (UTC)

FWIW, compare http://thefanzine.com/interview-with-peter-sotos-2/. - Jmabel ! talk 19:34, 22 June 2026 (UTC)

uploading beyoğlu to commons

hello there!

we are planning a project for the upcoming fall to visit, photograph, and upload to commons about istanbul's beyoğlu district and its surroundings, organize existing categories, and promote wikipedia and commons. the details will be finalized over the time. we will be applying for a rapid grant for this project. if anyone has experience in this area and would like to share their insights, they can reach out to me and kızıl. --Zemxer (talk) 19:22, 22 June 2026 (UTC)

Please help collect metadata wrong links

e.g. File:Bintulu Medical Centre.jpg#metadata has a wrong link to w:MI4 instead of w:Xiaomi Mi 4.

please write down any other such problematic links in the table. i will correct all of them together.

text	correct link	example
mi3	[[w:Xiaomi Mi 3|Mi 3]]	File:Ayuntamiento de Quintana del Marco.jpg
mi4	[[w:Xiaomi Mi 4|Mi 4]]	File:Bintulu Medical Centre.jpg
mi 5	[[w:Xiaomi Mi 5|Mi 5]]	File:Aland postbox mounted on sea ferry.jpg
mi 6	[[w:Xiaomi Mi 6|Mi 6]]	File:西.jpg
mi 8	[[w:Xiaomi Mi 8|Mi 8]]	File:云栖小镇国际会展中心01.jpg
mi 9	[[w:Xiaomi Mi 9|Mi 9]]	File:Guangfeng Niansidu Wushi Zongci 2019.05.02 14-26-03.jpg
mi 10	[[w:Xiaomi Mi 10|Mi 10]]	File:林嵩.jpg

note:

1. the correct link does not have to be enwp, but could also be commons category page (e.g. Category:Xiaomi Mi 4), wikidata item (e.g. Xiaomi Mi 4 (Q17413058)), commons category page of the manufacturer company (e.g. Category:Xiaomi smartphones (Xiaomi brand))... whatever you see fit.
2. if it links to special:search page on enwp, in other words it's not created on enwp yet, you can simply create a redirect from the link to the actual article of the phone or the phone series or the phone manufacturer. no need for me to fix it here on commons.

   only links to wrong articles or disambiguation pages need fixing.

RoyZuo (talk) 19:49, 22 June 2026 (UTC)

RFC about AI-generated content in Wikimedia Commons

You are invited to participate in a request for comment on Wikimedia Commons about a policy update for AI content. This may affect files that are uploaded to Wikimedia Commons for use on this project. Thank you. Codename Noreste (talk) 17:11, 23 June 2026 (UTC)

(This message was sent to Commons:Txokoa and is being posted here due to a redirect.)

Template:NSFW-Art

Sorry if I'm posting it in the wrong place, but I'm not sure what is the purpose of this template created by @Amogus502. I guess it is a sort of preventative measure against unwarranted deletion requests, though I'm not sure how effective it sould be. it can't be a disclaimer since that is already covered by the general disclaimer. It is also worth noting that a similar Template:Pornography was removed by @Jameslwoodward due to being "vague" after a deletion request started by @Dronebogus. Not sure if nominating this like the other template is a good idea, so I'd figure we should discuss the template with the person who created it as well as people who were against a similar template, plus others. Dabmasterars [EN/RU] (talk/uploads) 13:39, 23 June 2026 (UTC)

I agree that {{Pornography}}[9] is rather vague, although it was somewhat different from mine, whose scope is more defined and less broad, as I'm aware that not all drawings of nude people need such templates. I'm also aware that this is problematic, so I'll  Wait for more comments. Amogus502 (talk) 16:11, 23 June 2026 (UTC)

Commons:Village_pump/Proposals#c-Bawolff-20260605203900-Summary_2

a very recently user-made script could blur nsfw files according to users' own preferences.

so users need not worry about files being sent to deletion, because if that script becomes widely adopted, users who dont like certain files can just turn on the blur. RoyZuo (talk) 18:04, 23 June 2026 (UTC)

Great! Then could we deprecate the template and tagging it for speedy deletion (T2)? Amogus502 (talk) 18:35, 23 June 2026 (UTC)

Delete that tenplate, it’s not useful and redundant to the general disclaimer. Dronebogus (talk) 00:18, 24 June 2026 (UTC)

Don't we have Wikimedia Commons content descriptor (P14416) for this, now? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:41, 24 June 2026 (UTC)

Problems related to geographic categorisation

i'd like to ask if the community has written about/summarised the common problems related to geographic categorisation, and how we tackle the problems. that is, suppose we have a pair of coordinates (3, 9) and the name of its location "foo", over time:

1. foo came into existence at a certain point of time, let's say 1888.

   do we categorise an image of (3, 9) in 1777 under cat:foo?

2. the boundary of foo could change, so (3, 9) are inside the boundaries of foo only for a certain period of time (let's say 1999 to present).

   should an image of (3, 9) in 1900 be in cat:foo?

3. the name foo could change.
4. it's correct that (3, 9) lies inside foo right now, but what happens in future if that is no longer the case, because one of the above (boundary change, name change or formation/dissolution) happens?

similar problems also exist for wikidata and sdc. for example, suppose File:Sudan Juba cattle on street.jpg had location of creation (P1071) set to sudan in 2005, but then history was such that south sudan became independent in 2011, so where the image was taken is no longer sudan. what to do about this? solutions i can think of:

1. set qualifier "point in time"
2. remove the statement and replace it with the current correct one

if #1 is used, then a question is: is boundary change kept track of in wikidata?

if #2 is used, it's technically illogical, because a photo could not have been taken in south sudan in 2005. technically it was taken in "what was then sudan" or "what is now south sudan". RoyZuo (talk) 18:41, 23 June 2026 (UTC)

Comment: I think it can be useful to have categories that relate both to the legal jurisdiction at the time and those of the present day. For example, if an image shows Lviv in 1900, it is useful to have categories that relate both to Ukraine and to the Austro-Hungarian Empire; if an image shows Seattle in 1870, it is useful to have categories that relate both to Washington State and Washington Territory; etc.

Some of these cases (e.g. the Lviv one) can raise a lot of political sensitivities). Others (e.g. the Seattle one) really only raise issues of (1) ontology and (2) helping people find media. - Jmabel ! talk 22:30, 23 June 2026 (UTC)

I favor including images from a certain location broadly in the relevant categories, even if the political boundaries have changed. Categories are our main navigation tool so a a user looking for images in a certain location should not have to jump to a category tree of another country. "<location> by year" metacategories can be limited to only include the relevant political categories. MKFI (talk) 07:18, 24 June 2026 (UTC)

Opinions on preserving orthophotos on Commons

Jump to English

Deutsch: Mit der Archivierung von freien Orthophotos auf Commons und der damit verbundenen Datenmenge kam die Frage auf, ob es für Wikimedia-Projekte (und eigentlich auch der Wahrung freien Wissens) sinnvoll wäre, diese Datenmengen zu sichern, da sie eine größere Menge an Speicherplatz brauchen. Wie lautet Eure Meinung dazu? Orthophotos sind vertikale Luftbilder, die, ähnlich wie in Google Maps, eine Vogelperspektive auf die Erdoberfläche bieten. Momentan sind auf Commons große Teile der USA und Deutschland archiviert, meines Wissens auch teilweise die Schweiz und Österreich. Andere Länder bieten auch offene Geodaten an (Frankreich, Tschechien, ...). Im Folgenden möchte ich meine Argumentation unterbreiten, was dafür spricht:

1. • Es ist für Wiki-Projekte nützlich. Wir haben etliche geografische Orte, die noch kein (hochwertiges/aktuelles) Bild in Wikipedia haben. Die hohe Auflösung erlaubt sowohl das Einbinden von Strukturen wie Städten, Dörfern, aber auch kleineren wie Gebäudekomplexen (Unis, Schulen, Krankenhäuser, ...). Für Wikidata kann die Eigenschaft „Luftbild“ (P8592) genutzt werden. So können Millionen (!) Datenobjekte bebildert werden (Landkreise, Städte, Dörfer, Flughäfen, Stadt-/Ortsteile, große Straßen, Berge, Wälder, ...). Neben der Bebilderung können Daten für Wikidata abgeleitet und validiert werden.
   • Commons vs. IA: Es wurde auch schon hervorgebracht, dass Projekte wie das Internet Archive besser geeignet wären, nur leider bietet es weniger Interaktionsmöglichkeiten (Initiativen wie das ArchiveTeam archivieren Inhalte, die jedoch dann zwar im IA vorhanden, aber NICHT anzeigbar sind (Bsp. Satellitenbilder (archiviert, aber nicht zugreifbar)), das IA sieht sich des Öfteren die Existenz bedrohende Klagen ausgesetzt aus, und bietet weniger Interaktionsmöglichkeiten, vor allem für GIS-Anwendungen.
2. Die Menge an hochwertigem Luftbildmaterial kann von Freiwilligen nicht erbracht werden. Einige fleißige User haben mit Drohnen kleine Flächen als Orthophotos bereitgestellt. Aber ganze Bundesländer und Bundesstaaten können nur von professionellen Organisationen realisiert werden. Dafür werden etliche Mengen an Steuergelder investiert (schnell mal mehrere Millionen), um Daten zu erzeugen, die als OpenData jedem Bürger und jeder Bürgerin zur Verfügung stehen. Commons muss hierbei „lediglich“ als Speicher dienen, was finanziell eine deutlich geringere Last darstellt. Wir sprechen mittelfristig über mehrere Hundert Terabyte; Investitionen der WMF in Speicherinfrastruktur wären jedoch hier sehr gut angelegt. Dies klingt gerade für Privatpersonen evtl. nach viel, aber die Menge an gespeicherten Daten wächst rapide; das Internet Archive hat schätzungweise über 200 PB an einzigartigen Daten File:Unique data of the Internet Archive 20260105.svg; Commons ohne Thumbnails und Backups, etc. ca. 1,1 PB (Special:MediaStatistics). (Ich habe übrigens knapp 200 TB Speicher daheim rumliegen, als Vergleich). Ja, es ist viel an Daten, der Nutzen und die Einsatzmöglichkeiten sind es aber auch. Luftbilder sind gerade auf der zeitlichen Dimension nicht ersetzbar.
3. Sie stellen eine hohe Realitätstreue dar und dienen zur Prüfung von (historischen) Sachverhalten. Durch aktuelle, aber auch historische Luftbilder können Zustände und Situationen nachvollzogen werden. Wie wirkt sich das Waldsterben aus? Wie sah Köln direkt nach dem zweiten Weltkrieg aus? Welchen Einfluss haben Tagebaue, ... Auf Commons gibt es selbst Luftbilder aus dem Dritten Reich oder vor 1940. Dies ist für Wissenschaft und Forschung interessant, und geht über das Commons-Prinzip „edukativ“ weit hinaus.
4. Sie erweitern Commons um weitere Interaktionsmöglichkeiten. Während Commons vor allem zu Beginn zur einfachen Bebilderung mit JPEGs diente, haben sich die Möglichkeiten glücklicherweise deutlich vergrößert. Über animierte, bilinguale SVGs, 3D-Modelle (hoffentlich bald mit Textur), Videos mit vielsprachigen Untertiteln bieten Luftbilder als GeoTIFF nicht nur die Möglichkeit, diese einfach zu betrachten oder auf Wunschmaße zuzuschneiden, sondern auch ein Einbinden in Programme wie QGIS, die die Luftbilder gleich an die richtigen Positionen (dank eingebetteter Koordinaten) bringen. Dies könnte auch für kommende Wiki-Projekte oder Abgleiche in Projekten wie OpenStreetMap hilfreich sein, wo auch Geodaten eine immer wichtigere Rolle spielen werden (neben der reinen visuellen Darstellung). Orthophotos können als Basis für viele neue Projekte dienen. Ein lieber User hat große Arbeit geleistet, und die Luftbilder mit Geokoordinaten versehen, sodass sie auch auf Karten zu sehen sind (bspw. Sachsen). Dies macht auch die Suche nach Luftbildern von bestimmten Orten leichter, wenn man sich mit den Koordinatenbezugssystemen nicht so gut auskennt. Es ist richtig, dass diese Bilder große Mengen an Speicherplatz benötigen, aber sie denken ebenso enorm viele Elemente ab. Und gerade Wikipedia hat ja von etlichen geographischen Orten eigene Artikel...
5. Daten sind nicht garantiert dauerhaft verfügbar. Gerade unter Maßnahmen wie der Trump-Regierung oder durch Budgetkürzungen und Überschreiben alter Versionen können Datensätze an ihren Quellen gefährdet sein. Neben dem Nutzen für Wiki-Projekte dient Commons als freies Medienrepositorium (Wikimedia Commons als Quell der Summe freien Wissens) und ist in Zeiten von Fake News und dem Wachsen autoritäter und totalitärer Regime wichtiger denn je. Datensätze können leider verloren gehen oder nicht mehr zugreifbar sein, sodass sie irgendwo im lokalen Vermessungsamtsarchiv „verschwinden“ oder überschrieben werden, weil sie vermeintlich nicht mehr gebraucht würden.
6. Starker Gegenpol von kommerziellen Anbietern: Natürlich gibt es Karten für Google Maps wie von Maxar und anderen. Aber diese können nicht in freie Projekte eingebunden und verarbeitet werden, kosten ggf. Geld und können vom Zugriff verschwinden. OpenData-Maßnahmen können gar in Umfang und Qualität besser sein. Das Nutzen der GeoData-Angebote in Projekten wie Wikipedia könnte zeigen, dass Interesse vorhanden ist, und mehr Anbieter motivieren, Inhalte freizugeben, was dem Wikiversum auch zugute käme. Freie Geodaten sind demokratische Mittel gegen die Wucht kommerzieller Infrastruktur und können in viel mehr (Wiki-)Projekte interoperabel eingebunden werden, als statische JPEG-Dateien.
7. Nicht überall verfügbar: Freie Datensätze sind nicht für jedes Land verfügbar. Umso wichtiger ist es, dass es Länder gibt, die nutzbare Materialien haben.
8. Commons und Wikipedia sind zu bedeutend, um klein zu sein. Die Wikipedia und auch Commons sind eines der bedeutenden Portale für freie Medien. Sie sind weltweit bekannt und Wikipedia kennen so gut wie alle. Ich glaube, dies alles ist wichtig genug, um einen Schritt weiter zu gehen und die Commons wachsen zu sehen. Die Rolle von Commons als globales Medien- und Datenrepositorium spricht für eine langfristige Skalierung der Infrastruktur.

TLDR: Orthophotos sind keine bloßen großen Mediendateien, sondern eine einmal erzeugte, häufig nicht reproduzierbare und wissenschaftlich nutzbare Geodateninfrastruktur von langfristigem gesellschaftlichem Wert, die als Grundlage für Forschung, Bildung und freie Wissenssysteme dient. Sowohl das Wikiversum als auch die Allgemeinheit profitiert davon stark.

Was sind Eure Meinungen? (Vorangegangene Diskussion: https://phabricator.wikimedia.org/T427949, die das Thema etwas anschneidet)

English: With the archiving of free orthophotos on Commons and the associated volume of data, the question arose as to whether it would be beneficial for Wikimedia projects (and, in fact, for the preservation of free knowledge) to back up these data sets, since they require a significant amount of storage space. What are your thoughts on this? Orthophotos are vertical aerial images that, similar to Google Maps, provide a bird’s-eye view of the Earth’s surface. Currently, large parts of the United States and Germany are archived on Commons, and to my knowledge, parts of Switzerland and Austria as well. Other countries also offer open geodata (France, the Czech Republic, ...). Below, I would like to present my arguments in favor of this:

1. • It is useful for Wiki projects. We have numerous geographic locations that do not yet have a (high-quality/up-to-date) image on Wikipedia. The high resolution allows for the inclusion of structures such as cities and villages, as well as smaller ones like building complexes (universities, schools, hospitals, etc.). For Wikidata, the property “Aerial view” (P8592) can be used. This way, millions (!) of data objects can be illustrated (counties, cities, villages, airports, city/town districts, major roads, mountains, forests, etc.). In addition to illustration, data for Wikidata can be derived and validated.
   • Commons vs. IA: It has also been suggested that projects like the Internet Archive would be better suited, but unfortunately it offers fewer opportunities for interaction (initiatives like ArchiveTeam archive content that is then available on the IA but cannot be viewed (archiveteam_poes e.g., satellite images (archived but inaccessible)), the IA frequently faces lawsuits that threaten its very existence, and offers fewer opportunities for interaction, especially for GIS applications.
2. Volunteers cannot produce the volume of high-quality aerial imagery required. Some dedicated users have used drones to provide orthophotos of small areas. But entire federal states and provinces can only be covered by professional organizations. Significant amounts of taxpayer money are invested in this (quickly amounting to several million) to generate data that is available to every citizen as OpenData. Commons must “merely” serve as storage here, which represents a significantly smaller financial burden. In the medium term, we’re talking about several hundred terabytes; however, WMF investments in storage infrastructure would be very well spent here. This might sound like a lot, especially to private individuals, but the amount of stored data is growing rapidly; the Internet Archive has an estimated 200 PB of unique data File:Unique data of the Internet Archive 20260105.svg; Commons, excluding thumbnails and backups, etc., is approximately 1.1 PB (Special:MediaStatistics). (By the way, I have just under 200 TB of storage lying around at home, for comparison). Yes, it is a lot of data, but so are the benefits and potential applications. Aerial photographs are irreplaceable, especially in terms of the temporal dimension.
3. They provide a highly accurate representation of reality and serve to verify (historical) facts. Both current and historical aerial photographs allow us to reconstruct conditions and situations. What are the effects of forest dieback? What did Cologne look like immediately after World War II? What impact do open-pit mines have, ... Commons even includes aerial photographs from the Third Reich or from before 1940. This is of interest to science and research and goes far beyond the Commons principle of “educational value”.
4. They expand Commons with additional interactive features. While Commons was primarily used for simple illustration with JPEGs, especially in the beginning, its capabilities have fortunately expanded significantly. From animated, bilingual SVGs and 3D models (hopefully soon with textures) to videos with multilingual subtitles, aerial images as GeoTIFFs not only allow users to view them easily or crop them to desired dimensions, but also to integrate them into programs like QGIS, which place the aerial images directly at the correct locations (thanks to embedded coordinates). This could also be helpful for upcoming wiki projects or for cross-referencing in projects like OpenStreetMap, where geodata will play an increasingly important role (in addition to purely visual representation). Orthophotos can serve as the basis for many new projects. A kind user has done a great job of adding geocoordinates to the aerial photos so that they can also be viewed on maps (e.g., Saxony). This also makes it easier to search for aerial photos of specific locations if you are not very familiar with coordinate reference systems (ESPG:25832/25833). It is true that these images require a large amount of storage space, but they also capture an enormous number of details. And Wikipedia, in particular, has its own articles on quite a few geographical locations...
5. The long-term availability of data is not guaranteed. Data sets at their sources may be at risk, particularly due to measures such as those taken by the Trump administration or as a result of budget cuts and the overwriting of older versions. In addition to its utility for wiki projects, Commons serves as a free media repository (Wikimedia Commons as the source of the sum of free knowledge) and is more important than ever in an era of fake news and the rise of authoritarian and totalitarian regimes. Unfortunately, datasets can be lost or become inaccessible, so that they “disappear” somewhere in the local land survey office archive or are overwritten because they are supposedly no longer needed.
6. Strong counterpoint to commercial providers: Of course, there are maps for Google Maps, such as those from Maxar and others. But these cannot be integrated into and processed by free projects, may cost money to access, and can disappear from public access. Open data initiatives may even be superior in scope and quality. The use of geodata offerings in projects like Wikipedia could demonstrate that there is interest and motivate more providers to release content, which would also benefit the Wikiverse. Free geodata is a democratic tool against the dominance of commercial infrastructure and can be integrated in a much wider range of (Wiki) projects in an interoperable manner than static JPEG files.
7. Not available everywhere: Open data sets are not available for every country. This makes it all the more important that there are countries that have usable materials.
8. Commons and Wikipedia are too important to remain small. Wikipedia and Commons are among the most significant portals for free media. They are known worldwide, and virtually everyone is familiar with Wikipedia. I believe all of this is important enough to take the next step and watch Commons grow. Commons’ role as a global media and data repository argues for long-term scaling of the infrastructure.

TLDR: Orthophotos are not merely large media files, but a geodata infrastructure—once created, often irreproducible, and scientifically usable—of long-term societal value that serves as the foundation for research, education, and free knowledge systems. Both the Wikiverse and the general public benefit greatly from this.

What are your thoughts? (Previous discussion: https://phabricator.wikimedia.org/T427949, which touches on the topic somewhat).

Translated into English via DeepL, rechecked by me.

--PantheraLeo1359531 😺 (talk) 11:50, 13 June 2026 (UTC)

Addendum: I recently get notifications that orthophotos are used and cropped for Wiki projects, so there is resonance in usage --PantheraLeo1359531 😺 (talk) 11:50, 13 June 2026 (UTC)

I have no doubt that they are of value; the question should be phrased as whether they are of enough value to merit the storage costs and other overhead. That cannot be answered intelligently without a good estimate of the costs and overhead involved. - Jmabel ! talk 22:20, 14 June 2026 (UTC)

157TB is actually ridiculously large, so this is worth discussing. However it feels like a WMF Ops view would be sensible. If there are server systems that 'park' very large collections differently when not actively in use, it would be illuminating in assessing the types of 'cost'. This discussion seems premature while the phab discussion is on-going as the options for compression might make a game changing difference. Past experience of the TIFF wrapper indicates that it is often a terrible way to store lossless images due to huge file sizes. There are alternative formats but as the storage challenge is important to get right, it would be super if some practical test examplars could inform discussion before mass changes are agreed. Fæ (talk) 02:59, 15 June 2026 (UTC)

BTW on "large", if using HDD arrays, storage for over 250 TB would be around $500 a year in capital and running cost, based on online estimates. Even if I am misunderstanding and the reality is ten times that, it's not a lot compared to employing one full time Ops person. Fæ (talk) 03:18, 15 June 2026 (UTC)

The problem with TIFF is that lossless files in TIFF used LZW when that patent business came down, and combined with the massive options TIFF offers, many groups used TIFF with no compression for archiving. TIFF files can be seamlessly recompressed to LZW or Deflate/Zip compression, and doing so with File:Nighthawks_by_Edward_Hopper.png (an 87 MB file) produces 84MB or 80MB files. (LZW is more standard, Deflate is a bit higher compression but only supported in 21st century TIFF products.) If you remove the interlacing from the PNG file, it drops to 73MB. Either way, the largest is 20% larger than the smallest, and both of those are PNG versions.--Prosfilaes (talk) 04:14, 15 June 2026 (UTC)

Here we are talking about geodata raster tiles. These tiff files are often very good to compress. The problem is that the compression can not be done directly to the file as this causes problems with GIS software. GPSLeo (talk) 06:07, 15 June 2026 (UTC)

We had a test lab project called Commons Archive that had a similar function, but it was not maintained and eventually deleted. If someone were willing to maintain Commons Archive again, then I think it would be a valuable addition. ―Justin (koavf)❤T☮C☺M☯ 06:10, 15 June 2026 (UTC)

I personally think that this is not what Commons is for. Sure if there is a specific need to upload a file in a certain context. but we can't host all of this. Don't forget that it is not just the raw data. each images is a page, and revisions, and links to categories (which are already a problem). A dedicated archive is a much better fit for this than a general purpose media hosting service inside of a Wiki. So if people want to do this (which I'm not against) then make a website for it that specializes (technology wise) in being an archive for this. —TheDJ (talk • contribs) 09:10, 15 June 2026 (UTC)

I wasn't aware these existed, but this could be incredibly useful on the projects as tiles for the template:maplink tool. (the currently used tiles are an ancient version of the tiles from OpenStreetmap, With that kind of usage, I think hosting these would be within the Commons remit. Milliped (talk) 09:41, 15 June 2026 (UTC)

I can understand the raised concerns, and it's without a doubt a huge dataset. Of course, the most important aspect is the archiving itself, so the images are preserved. If it is only about the archiving as such, argumenting to keep it on Commons may be challenging and difficult.

However, when considering the diverse use cases across Wikimedia projects, I see substantial value in hosting them here. If we, for example, have coordinates of a Wikidata item and the bounding box of an orthophoto, we could link the image to the respective Wikidata item where the orthophotos contains the motif. Orthophotos are also useful as illustrations for Wikivoyage and of course, Wikipedia. A single image may contain hundreds or even thousands of potentially notable objects.

I think one major disadvantage of a pure archive is its rigidity. Discovering, reusing, and integrating content into Wikimedia projects becomes significantly more difficult or even restricted. Commons, on the other hand, is built around accessibility, reuse, categorization, and interconnection.

As geographic landmarks are distributed across the territory, we have a high information density with useful resolution, even in sparsely or unhabitated areas. And in some cases, orthophotos may be the only imagery we can get for illustration, particularly where ground-level photography is difficult or where drone usage is restricted or prohibited.

I would also emphasize that Commons itself has evolved considerably over time. It started primarily as a repository for relatively simple image files by hobby photographers, but has since expanded to support video, audio, structured data, multilingual media, 3D models, and immersive formats such as spherical panoramas, up to professional photographs and historical GLAM material. Commons increased its diversity of media, where orthophotos are a next (logical) step. In that sense, they do not simply add more files to Commons—they add a new dimension to what Commons can represent and support. It enriches Commons, as it allows a new dimension of media.

Many Wikipedia contributors feel the frustration when they are lacking media. Some areas may not cover an eager Wikipedian, who could drive a longer route and take pictures. As Commons has a narrow scope with only hosting very free usable media, acquiring media is hard. The fact that there is high-quality media outside, useful for the Wiki movement, is a big chance in my eyes. So or so, if the ongoing compression is done, we also have a decrase in disk usage, which is also a positive aspect coming into this discussion. --PantheraLeo1359531 😺 (talk) 19:39, 15 June 2026 (UTC)

I suspect that the biggest hurdle here is that Commons is not well suited to indexing so many basically parallel files. Our approach of having a distinct file page for each file may not work well here; at the very least, some sort of templating is in order. I'm wondering about whether there may be some potential here of placing descriptive metadata in a database (something much more efficient for table-like data than Wikibase) and drawing from that on demand via templating. I'm out the door and don't have time right now to flesh this out, but just wanted to jot this down I'll try to expand on it later if no one beats me to it. - Jmabel ! talk 20:15, 15 June 2026 (UTC)

The concept of a "class" of files with no filepage apart from a single common one, because they are effectively records in a database sounds great. How a possible new namespace (the current 'data' space is near redundant) or closer ties to wikidata could help bypass this traditional system needs some careful thought. A clever solution and I like it; is it "wikimedia.commons", that's the fundamental wiki design discussion that drops out. Fæ (talk) 11:17, 17 June 2026 (UTC)

Generally, I'm open towards hosting orthophotos. We already host batch uploads of ISS flyovers, which are thousands of files, usually unsuitable for encyclopedic usage. And yet, there are the shining 1% examples of these files being useful to illustrate WP, which is why we host them.

Jmabel's idea of templating is worth thinking about. There is also the idea to store the images in a database that enables tiling, mosaicking and pyramidizing... as is generally done with large geographic datasets these days. We should also consider to which extent we want to store orthophoto timelines: Early orthophoto archives already exist for the 1940s; more recently in Germany I know that new sets of Orthofotos (DOP) are produced regularly. Depending on the area, every two years or five years. So our templates should allow skipping towards older/newer photos of the same area, ideally by naming the sets alike. Which needs masterful standardization.

Also, how are we going to deal with cropping? There are some people who will absolutely run the crop tool day and night to crop their favorite features from the DOP imagery: Just check out this example or this one. I'm near-certain that some users will locate and crop DOP images to illustrate for example their WP articles on local churches. That is okay, we want church articles to be illustrated with DOPs - but wouldn't it be better to do so with a WMS framework similar to the existing WikiMap, so that Common's doesn't have to host hundreds of additional cropped files per original DOP? I'm not up to date on the technical possibilities, but dynamic CSS cropping is what I would prefer.

We need to plan ahead, I think. For example with Sanborn maps, there are no functions that enable skipping from a 1888 survey to the following 1908 survey. If a connection can be made between two timeframes, users have to find and connect the files themselves. With maps, georeferencing etc could solve some issues, but the maps are already uploaded without georeferences, which actually applies to most maps. Measures now have to be taken after the fact of twenty years of uploaded material, which hinders standardization. Similarly in the case of #Maps from Our World in Data, Doc James has not for a day stopped uploading maps into a frankly crappy category scheme that was never meant for what it is currently (ab)used for. We even have agreement on how the category scheme/framework needs to look like, but still we only got the promise that proper categorization will be done. Eventually. Hopefully. Once the current plan of 2 million uploaded maps is completed. Maybe by someone else. A bot. Or by myself on my lonely own, for the next twenty years. Who knows.

All I'm saying that we should carefully consider how the new material can be organized, and before it is uploaded. --Enyavar (talk) 14:51, 17 June 2026 (UTC)

 Support This sounds to be a good idea to me --PantheraLeo1359531 😺 (talk) 14:15, 24 June 2026 (UTC)

ultimately, i don't think we should make decisions based on scaling concerns. If the DB schema is running into scaling issues, WMF should invest money into sharding or whatever is needed. Yes resources are finite and resources spent on one thing are resources that cannot be spent on another. However we are no longer in a shoe string budget and having lots of pages is the core functionality of wiki software. This is not an area we should ask the community to make trade offs in. Bawolff (talk) 16:05, 20 June 2026 (UTC)

"This is of interest to science and research and goes far beyond the Commons principle of “educational value”"—I fail to see how anything "of interest to science and research" can be said to go "far beyond the principle of educational value". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:49, 20 June 2026 (UTC)

I think the orthopods should just go to Internet Archive. Take one of procedures of grants, namely adding files if an majority of the files will be linked on a WMF project. Some arguments: First, Commons was started after several Wikipedia versions had the same free files. There is an wikitech mailing list message on this. Archival was not the goal of founding commons. Second, WMF sites like pictures of specific locations, so the orthopod pictures would be edited anyway. Third, creating an free Internet Archive account does unlock some files on their website, whether orthopods are included I do not know. Snævar (talk) 14:11, 23 June 2026 (UTC)

"orthopods" => "orthophotos", I presume. I saw that last as a diff in its own right and did a proper Emily Litella: "What's all this about orthopedic surgeons and the Internet Archive?" - Jmabel ! talk 22:15, 23 June 2026 (UTC)

I think this argumentation lays too much on the mere archival issue. Apart from the problems that IA is (potentially) facing, I would like to remeber on how the files can interact with Wiki projects.

Of course, single croppings can be useful, but they often lose the broader spatial context contained in the full orthophoto. A cropped image may illustrate a single object, whereas the complete orthophoto can document an entire area and the relationships between its features.

The IA primarily covers the preservation as such. But on the other hand, Commons can add metadata like geo-tagging, aerial coverage of areas (and across the timeline) and more. This makes discovery, reusing looking up and maintenance easier. If we just dump altogether in the IA, searching will become harder (especially for not versatile users).

Also, the imagery contains a lot of data. This data can enrich Wikidata. It allows us to verify locations, measure distances and areas, document the development of settlements over time, and provide spatial context for countless geographic objects. Things can be validated AND rechecked. The point is that we do not just archive them; we make them interactive and useful within the Wikimedia ecosystem. That is a significant added value.

In short: The key difference is that on Commons we do not merely preserve the files. We make the files discoverable, reusable, and connected to the wider Wikimedia ecosystem. That additional layer of interaction is a significant advantage over a solely archival solution. The topics hang together. --PantheraLeo1359531 😺 (talk) 14:39, 24 June 2026 (UTC)

These are good points. The tool I proposed here would make adding the metadata more easy. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:18, 24 June 2026 (UTC)

Seems fine to me, with the added information. Snævar (talk) 18:49, 24 June 2026 (UTC)

Commons was not explicitly created to permanently preserve files, while Internet Archive was. Then, you see that files in Commons have at least 8 copies in 2 datacenters, with thousands of km between them, that even deleted files aren't physically removed from servers nor backups, and we have deleted files marked as "undelete in 2055" or the like, that WMF has more money than it needs, even if it stored several times the total size it stores, etc. And that, ten years ago, Internet Archive had an infrastructure that had most of its content continuously one step from disaster, and there is no truly reliable information that can make us 100% confident that the current situation is far more better ("a copy in Canada", but some sources say it's a full copy, while others say it's only partial).

So, maybe, decades from now, history will provide an interesting example to learn from it. Those who wanted to preserve everything forever, didn't care about the physical means to achieve that, and a catastrophic loss happened. While Commons, without having long-term preservation explicitly in mind, followed the minimal standard backup practices and kept lots of media files preserved for future generations, even without being its primary intention. That's why I think that long-term thought should be present in Commons: we are almost there, probably, just inertia will preserve all the files currently in Commons for the next century (even most deleted files, while not publicly visible). On the other hand, Internet Archive will need to improve a lot in many ways from its 2016 situation, to be close to achieving the same goal. MGeog2022 (talk) 14:01, 25 June 2026 (UTC)

I think that the diskspace is not a problem for any still images. Ie. global storage market is focusing on storing for example video which will take one magnitude more space than images and this will drive storage capacity up and prices down per TB. So my vote is keep. --Zache (talk) 14:12, 25 June 2026 (UTC)

How should we get photos of famous people, which are decent?

I mean decent resolution and good enough the subject will be at least okay with it. So we won't get more cases like Zara Larsson, I mean, complaining about their photos here.

I'm not sure if a very good one can be taken. One of the very good was Charlie Kirk's one, taken by Gage Skidmore. The photo was so good it was made his profile picture. — Preceding unsigned comment added by Candidyeoman55 (talk • contribs) 17:28, 24 June 2026 (UTC)

Commons:WikiPortraits is a project addressing this. It's also getting more common to be able to find a reasonable quality video still on YouTube, where a person has been interviewed or hosted by a channel or institution that releases its video content under a CC licence.

It would also be great if more people (both celebrities and people who reply on social media to celebrities) were aware that posting a selfie to social media is enough, so long as it has the right licence statement on it. --Belbury (talk) 17:38, 24 June 2026 (UTC)

The best best way is always to make the photo yourself. If you need some accreditation to attend an event as photographer ask you local chapter for assistance. GPSLeo (talk) 18:17, 24 June 2026 (UTC)

But then don’t be a (unintentional) creep about it. There’s been a few embarrassing situations where the person felt uncomfortable by the way they were asked for a photo. Please exercise the utmost level of care and consideration, these people have to deal with stalkers all the time and at first glance, such a request can easily be mistaken for stalking or otherwise invasive behavior. —TheDJ (talk • contribs) 22:45, 24 June 2026 (UTC)

When famous people are on a stage there are always many photographers. This why I suggested to go to such events and not to ring at the door of the persons home. GPSLeo (talk) 04:40, 25 June 2026 (UTC)

A few remarks here:

• The Zara Larsson situation was an outlier: we've had plenty of "decent" images of her for a long time but also lots of efforts in her en-wiki article to insert copyvios, fake images, etc., and to opt for oddly uncomplimentary choices from among what we've already got. I don't really love the one we've ended up with in the Infobox at en-wiki (too specific to particular stage makeup, not likely to be useful to identify her in any other context) but I gather she likes it better, and at least we could form a consensus.
• While I think we should generally want the prominently-featured photos in an article to be reasonably complimentary, we are not part of someone's publicity apparatus, and we are not compelled always to pick the photo that the subject (or their representative) likes best. Sometimes that results in a very bland, generic head shot or stylized performance photo that fails almost completely to capture the person, whereas we may have some much better portraits of them.
• Nothing against WikiPortraits, they are doing a lot of good work, but people sometimes seem to see this particular group as now being the be-all and end-all. This isn't the place to go into where my aesthetic for my own photography differs from their prevailing aesthetic, but I'll say that there are a lot of excellent photos on Commons shot in a lot of different styles, and we're the richer for it. - Jmabel ! talk 02:15, 25 June 2026 (UTC)

The Zara Larsson situation doesn't really seem to be about getting a decent photo, but more about the person wanting to be represented a specific way. To me at least, the old photo looks more complimentary than the current one, but it seems reasonable enough to follow the person's wishes when they are reasonable and not misleading, which seemed to be the case in that situation. However, I don't see how we could possibly avoid that situation, its not really possible to read the subject's mind, and I don't think there was anything objectively wrong with the old photo. There are lots of Wikipedia articles with much worse photos. The only thing I think we reasonably could do differently is somehow promote to people that if they don't like their photo they should first complain on the talk page and if necessary donate an alternative, instead of complaining on tiktok. Bawolff (talk) 05:26, 25 June 2026 (UTC)

just a random idea.

how about making a toolforge app, that's like a passport photo maker? a simplest way to streamline the whole process of submitting a selfie, from registering an account to taking the selfie to uploading to having it properly categorised.

there are a lot of people's wp articles without pics, for example many athletes (in not very commercial sports) and professors. if there's such an app, and when the infoboxes on wp have no pics they provide a link to this app, maybe when the subjects see their empty profiles they are quite likely happy to upload selfies. RoyZuo (talk) 09:07, 25 June 2026 (UTC)

The hardest part is for anybody reasonably famous, you probably need to go through VTRS or otherwise get them to prove they really are who they say they are and are actually licensing the photo. Bawolff (talk)

i was thinking of the webapp using the phone/laptop camera to take a photo. i'm not sure how hard it is to cheat that with a fake.

and these photos can be uploaded to a buffer to wait for commons users to approve. ask them to submit a photo from third party sources (e.g. news articles) for cross corroboration to make checking easy.--RoyZuo (talk) 22:35, 25 June 2026 (UTC)

Recategorization of Wikipedia's anniversaries

Hi everyone, I was just working on organizing the categories for Wikipedia's 25th anniversary in the Netherlands, and that's when I noticed something. There is a category named Category:Wikipedia Day 2026 (which links to Category:Wikipedia 25) and Category:25th birthday of Wikipedia (which also links to Category:Wikipedia 25). However, this is not the case for almost all other Wikipedia anniversaries. To give an example: we have Category:Wikipedia 5, Category:Wikipedia Day 2006, and Category:5th birthday of Wikipedia. Category:Wikipedia 5 links to Category:Wikipedia Day 2006, but Category:5th birthday of Wikipedia stands on its own and has different content. How does this work exactly? What's the difference between Wikipedia Day followed by a year, a birthday of Wikipedia, and Wikipedia followed by a age? It seems to me that it would be better to put everything into a single category for the overview (with the other two categories linking to it), but what would be the best name for that category?

1. Category:Wikipedia [age]
2. Category:Wikipedia Day [year]
3. Category:[ordinal number of age] birthday of Wikipedia

I would appreciate hearing your opinions. Kind regards, Perquirius (talk) 17:16, 21 June 2026 (UTC)

I think the "Wikipedia Day" formulation is probably easiest to maintain over time, and the least error-prone. My least favorite is Wikipedia [age], where I'd never guess the meaning from the category name. - Jmabel ! talk 22:35, 21 June 2026 (UTC)

Thank you! I will change everything to "Category:Wikipedia Day [year]". Kind regards, Perquirius (talk) 13:43, 26 June 2026 (UTC)

Never mind. It's too much work to do this manually, since I don't know how to do it all at once. Kind regards, Perquirius (talk) 13:46, 26 June 2026 (UTC)

I'll propose this in a CfD. It's not tough to do, but the people who created the affected categories need to be notified and have a chance to object. - Jmabel ! talk 02:51, 27 June 2026 (UTC)

Thank you, Jmabel! Kind regards, Perquirius (talk) 08:29, 27 June 2026 (UTC)

Re: Court Order Concerning Commons Image Related to the 2026 Onikişubat School Shooting

This is BChoo (WMF) (talk · contribs) writing on behalf of the Wikimedia Foundation's legal department. We wanted to follow up on the discussion now archived at Commons:Village pump/Archive/2026/06#Court Order Concerning Commons Image Related to the 2026 Onikişubat School Shooting.

Omphalographer (talk · contribs) asked if we could share the content of the takedown order, the WMF's objection, and/or the rejection of the objection. I have uploaded the 24 April 2026 takedown order and the 13 May 2026 rejection of the objection to Foundation Wiki (personal data redacted, in Turkish). We hope this is helpful. BChoo (WMF) (talk) 20:13, 26 June 2026 (UTC)

Thanks for this. ―Justin (koavf)❤T☮C☺M☯ 20:21, 26 June 2026 (UTC)

Thanks for following up on this! I have to admit I don't read Turkish myself, but I do hope that the text of the order will help inform discussions surrounding it. Omphalographer (talk) 20:41, 26 June 2026 (UTC)

Is there a reason this can't be hosted on Commons? I dont know if Turkey typically copyright's it's court documents Trade (talk) 22:05, 26 June 2026 (UTC)

Part of Law No. 5846: Art. 31. The reproduction, distribution, adaptation or exploitation in any other form of laws, bylaws, regulations, notifications, circulars and court decisions that have been officially published or announced is permitted.

My reading is that the documents at wmf can be copied to Commons and could be transcribed and translated via wikisource ({{Legislation-TR}}), if anyone wants to try? --Fæ (talk) 09:21, 27 June 2026 (UTC)

The wikisource way is to run the pdf through en:Optical character recognition (OCR) and then fix it on wikisource, in this case turkish wikisource. https://ocr.wmcloud.org/ or the Internet Archive will work for OCR. The text will be selectable in the pdf file after OCR. Ask turkish wikisource on their village pump if they want to participate. Snævar (talk) 14:30, 28 June 2026 (UTC)

So from my amateur understanding the Turkish judgeship demands the file to be taken down for being in violation of "Law No. 5651, Article 8" which applies to things such as "obscenity, suicide encouragement and child abuse". In the second PDF the judgeship changes their reasoning to "Article 8/A" which is a law that allows for the state to prohibit media that "threatens the national security and public order" such as "terrorist propaganda", "blueprints for terror attacks", "incitements to riots" and similar things --Trade (talk) 22:16, 26 June 2026 (UTC)

• Court order documents (transferred to Commons)
• 
  2026-1300
• 
  2026-1570

The Biodiversity Heritage Library might be at risk

Hi! A couple days ago, I find this Guardian article. It contains 64M pages of historical works of species and nature. Unfortunately, due to sparse fundings, it's online access is at risk. As it offers many historical and valuable arts, it is (mainly) public domain and educationally useful. I don't know how much Commons covered it yet, but it may be an important preservation project to transfer files from there. All the best!

Addendum: Commons seems to have about 305k files from there: Biodiversity Heritage Library --PantheraLeo1359531 😺 (talk) 08:09, 23 June 2026 (UTC)

I believe most (all?) of the files in the Biodiversity Heritage Library are hosted on the Internet Archive (along with millions of other, non BHL items), while the BHL interface provides indexing and search functions. So the Internet Archive is the repository/backup, but is itself vulnerable to occasional attacks or outages rendering the BHL non-functional as explained here. Also, importantly, not all content on BHL or Internet Archive is under a free license. --Animalparty (talk) 00:40, 24 June 2026 (UTC)

As the uploader of most of what we host from the BHL, we are significantly constrained by copyright. A search on IA shows that around 14% of the BHL collections can conservatively meet the free license requirement. A 'refresh' is running which adds at least approx 6,000 documents; this could be an underestimate depending on how many additional older (19th C) items have been shared with IA.

A key difference between Commons and IA is that we are not allowed to use JPG2000 format which is how the pages scanned by the BHL are archived as a lossless format. Embedded in the pdfs uploaded are very slightly more compressed JPEG format versions of these scans. This is not noticeable to the eye, but it's a technically uncomfortable point if Commons is supposed to host archive quality versions. Discussions and tests on this are in the VP archive from several years ago. (Note phab:T13871 where Brooke (WMF at the time) stated "If there's a strong interest in JPEG 2000 -- such as an institution desiring to share a large number of original files in this format -- then we could probably have WMF Legal do some more thorough research. But historically there's been little demand so far.")

If someone thinks there's a large amount of BHL content on IA that has been missed which *definitely* meets COM:L, like early U.S. federal works, drop a note about it on my talk page. --Fæ (talk) 01:31, 26 June 2026 (UTC)

Thank you for the detailed answer. I was not sure about the coverage on Commons, so I just wanted to reach out about potential problems about the endangered source --PantheraLeo1359531 😺 (talk) 09:51, 29 June 2026 (UTC)

Commons:Harassment

Hi, This is an essential policy of Commons, and I am very surprised that it is not yet translated. Please help. Yann (talk) 07:12, 26 June 2026 (UTC)

+ Commons:No personal attacks, Commons:Civility. Yann (talk) 13:39, 26 June 2026 (UTC)

Those are long pages. Can we have summaries (like "nutshells" found in other policy pages), and translate them first?

Also, revisions should ideally be made first, in order not to waste translators' time. I believe they became official with the understanding that necessary revisions will be made. For instance, I think Commons:No personal attacks needs some refinements from the fact that we don't have exactly the same kind of content disputes to Wikipedia's, especially "article" disputes. [10] More generally, these pages were imported from English Wikipedia with little changes, and the way they are written seems a bit out of place to me, even if Commons and Wikipedia share the same core ideas about behavioral issues. I'm sure English Wikipedia has its own justification and history for those documents to have evolved in their current forms, but Commons doesn't have the same history, and can use more succinctness (although I accept that such rewriting would not be easy). whym (talk) 03:13, 1 July 2026 (UTC)

Reviewing/revising the text before translation is a good idea.

There are also grammar error(s), such as this:

It is important not to post comments that others may reasonably be interpreted as a legal threat.

In my understanding, it's either "that by others may (...) be interpreted (...)", or "that others may (...) interpret as a legal threat."

As to translation volume, we're talking about some 8000 total words for the three policies:

Harassment (3000 words) – No personal attacks (1500 words) – Civility (3500 words )

In traditional-style, manual translation, that's some 3 days of work for an experienced translator. With automated or AI pre-translation, it can be done faster but will still require careful review/reworking.

Personally, I find the 3500 words of "Civility" quite OK, as that page is written in tips-and-tricks style. – Regarding "Harassment" on the other hand, with its semi-legal style, I wonder if that page might be condensed to some 2000 words (i.e. to a size more like that of "No personal attacks")? -- Martinus KE (talk) 12:45, 1 July 2026 (UTC)