Shortcut: COM:VP

#	💭 Title	💬	👥	🙋 Last editor	🕒 (UTC)
1	German currency files without machine-readable license	10	2	Jarekt	2024-07-19 23:52
2	POTY (Picture of the Year) competition needs help!	7	6	Giles Laurent	2024-07-19 18:01
3	Potentially confusing page naming	7	4	LPfi	2024-07-13 19:51
4	STL files visualization	5	3	Prototyperspective	2024-07-16 11:12
5	Deletion nominations using only no-fop as reason	10	5	Smiley.toerist	2024-07-16 16:04
6	Potential copyright problem -- best course of action?	3	2	Rlandmann	2024-07-13 22:52
7	File:Baron Moncheur, F.R. Coudert, W.D. Robbins LCCN2014719398.jpg	2	2	Geohakkeri	2024-07-13 15:51
8	Category:2024 shooting at a Donald Trump rally	8	5	PantheraLeo1359531	2024-07-15 07:24
9	New version of the upload wizard doesn't seem to collect enough licencing information	3	3	Sannita (WMF)	2024-07-15 08:55
10	Category:Charles Darwin	3	2	Richard Arthur Norton (1958- )	2024-07-15 03:31
11	Commons talk:Media knowledge beyond Wikipedia	1	1	MGeog2022	2024-07-14 17:50
12	Photo challenge May results	1	1	Jarekt	2024-07-15 01:19
13	Works of art of men smoking (activity)	4	4	ReneeWrites	2024-07-19 05:53
14	What are free media resources for illustrations?	1	1	Prototyperspective	2024-07-15 13:19
15	Psilota decessa -> Psilota decessum	11	5	Crawdad Blues	2024-07-17 16:06
16	Oak Island's map	5	2	Tylwyth Eldar	2024-07-19 05:26
17	Category:Flickr streams/Category:Photographs by Flickr photographer	9	5	Prototyperspective	2024-07-19 11:11
18	Unsourced data on Commons?	5	3	Prototyperspective	2024-07-17 15:38
19	Mysterious Intel microprocessor/IC	2	2	Glrx	2024-07-18 04:09
20	Results of Wiki Loves Folklore 2024 is out!	1	1	Rockpeterson	2024-07-18 08:25
21	empty sub-categories of Category:EuroGames_2024_Vienna	1	1	Zblace	2024-07-18 10:11
22	Book covers' copyright	2	2	Geohakkeri	2024-07-18 10:44
23	Wikimedia Movement Charter ratification voting results	1	1	MediaWiki message delivery	2024-07-18 17:51
24	Alphabetical string function	11	4	Sbb1413	2024-07-20 03:32
25	Freedom of panorama for photos taken across the border	4	3	A1Cafel	2024-07-19 05:59
26	Glitch	3	3	Speravir	2024-07-19 23:57
27	Video question	4	2	PantheraLeo1359531	2024-07-19 19:08
28	Pre-implementation discussion on cross-wiki upload restriction	7	4	Adamant1	2024-07-20 14:58
29	License change	4	3	Jmabel	2024-07-20 15:58

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

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

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

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

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

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

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

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

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

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

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

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

I suspected it might be something like that, sadly.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We have both Commons:Primeiros passos and Commons:First steps/pt with the level-1 heading "Primeiros passos". This seems potentially very confusing. Any thoughts? - Jmabel ! talk 18:26, 8 July 2024 (UTC)[reply]

Easy, like it or not, English is the default language for the project. It's a pragmatic decision, and obviously assists search. Other languages can be echoed by creating a companion page in Wikidata. Broichmore (talk) 19:10, 8 July 2024 (UTC)[reply]

@Broichmore: one of us is missing the other's point; I'm not sure which. For Portuguese-language users, this results in two rather different pages that effectively have the same title. Are you saying that's not at all a problem, or not one worth fixing, or something else? And I can't see what Wikidata has to do with the matter at all. - Jmabel ! talk 00:09, 9 July 2024 (UTC)[reply]

Yes, I missed the point. The two pages should, could be, amalgamated TBH. Broichmore (talk) 10:00, 9 July 2024 (UTC)[reply]

On closer look, this seems to be a problem also for Commons:First_steps/de and Commons:Erste Schritte and around 20-30 more languages (everything in {{Header|Lang-FS}}) as a lot of these translations were created pre-2010 before we had mw:Extension:Translate. Ideally, they should be redirected to the correct version (Commons:First steps/xx) (the versions are so different there's little point merging). —Matrix(!) {user - talk? - _uselesscontributions} 10:34, 9 July 2024 (UTC)[reply]

But that seems to raise the question of whether Commons:Primeiros passos, Commons:Erste Schritte, etc. have some content worth preserving.

I'd suggest that some people whose native language is other than English might want to look into this for their respective native language. - Jmabel ! talk 16:54, 9 July 2024 (UTC)[reply]

There is also the question whether these pages should be translations from an original in English or edited freely by the community. Should the "content worth preserving" be translated and added to the English version or added to the translated page in pt/de/…? What about things that are especially relevant for many speakers of the other language, such as references to local law or clarifications generally not needed for the Anglosphere? –LPfi (talk) 19:51, 13 July 2024 (UTC)[reply]

Hi all, for the past few weeks, I haven't been able to view STL files that are uploaded to Commons (for example these: Category:STL files from Museo di storia naturale dell'Università di Pisa). The thumbnail shows up fine, but when I click on the eye icon, I get an error message, that reads "Sorry, the file Undefined cannot be displayed since it is not present on the current page. Go to the corresponding file page". The last sentence is a link, but leads to a non-existent "Undefined" page. Up until a few weeks ago, a window would open with the 3D image, which I could rotate and view. Any idea what's going on? Thanks a lot! --Marta Arosio (WMIT) (talk) 12:20, 12 July 2024 (UTC)[reply]

Yes, unfortunately, the 3D functionality on Commons is not very well curated. A requested feature to be able to upload textured meshes is also stuck for years now. We as community hope that these issues will be adressed, but until now, nothing huge happened :( --PantheraLeo1359531 😺 (talk) 14:05, 12 July 2024 (UTC)[reply]

Created the issue a few weeks ago here

Tracked in Phabricator
Task T368301

Prototyperspective (talk) 14:46, 12 July 2024 (UTC)[reply]

Thanks @Prototyperspective: ; I am noting now that the 3d rotation is indeed still accessible, if you click on the miniature within a Wikipedia article. The page that opens then presents the image that can be rotated. This does not work clicking on the same miniature on Wikidata. For an example, see this file File:Panthera pardus 3d scan Natural History Museum University of Pisa C 1389.stl on this article w:Leopard. --Marta Arosio (WMIT) (talk) 09:34, 16 July 2024 (UTC)[reply]

Thanks, didn't know STL files still work on Wikipedia. I'll add this info to the code issue. The file does open and rotate on Wikidata on my side so maybe that got fixed since your comment or there is some issue in your browser. Prototyperspective (talk) 11:12, 16 July 2024 (UTC)[reply]

Example: Porta Susa old station building 2016 4 This is the old station of 1856, not the New one. So some explanation as to why this building is protected is needed. The same for the nummers 1 to 3. Smiley.toerist (talk) 07:23, 13 July 2024 (UTC)[reply]

Courtesy links:

• File:Porta Susa old station building 2016 4.jpg, and
• Commons:Deletion requests/File:Porta Susa old station building 2016 4.jpg.

Commander Keane (talk) 10:19, 13 July 2024 (UTC)[reply]

From the perspective of the deletion nominator, Template:NoFoP-Italy says This image features an architectural or artistic work, photographed from a public space in Italy, which is true for the deleted picture... Maybe it should make it clearer with something like This image features a recent architectural or artistic work, photographed from a public space in Italy. Maybe User:Mazbel can shed some light on the error. Commander Keane (talk) 10:35, 13 July 2024 (UTC)[reply]

@Commander Keane@Smiley.toerist anything in public domain is PD. Free to be licensed under commercial CC licensing. Italy is a Berne signatory, and current Berne Convention rules prohibit copyright renewals (reflected in the 1940s copyright law of Italy that is the law in force today), so it is unlikely the architect's grandchildren can claim copyright over a work that has fallen into PD. Those DRs must be closed as keep. JWilz12345 (Talk|Contrib's.) 10:45, 13 July 2024 (UTC)[reply]

@Commander Keane: Regarding what I was tagged, when it came to nominating it to DR, I relied on the template description as mentioned above, being a work of architecture. Thus, the error can be attributed to the unclear text you quoted at the beginning. On the other hand, (correct me if I misinterpreted), did the second quote correspond to a suggestion to change the text of the template? Finally, as JWilz12345 makes explicit, grandchildren are unlikely to claim copyright to a work that has already fallen into the category of PD.--Mazbel (Talk) 03:11, 14 July 2024 (UTC)[reply]

@Mazbel was that template tagged at those four images? If so, that tag should be removed from the said images. You may want to replace it with {{PD-old-architecture}} (only for PD buildings in no-FoP countries). JWilz12345 (Talk|Contrib's.) 03:14, 14 July 2024 (UTC)[reply]

@Mazbel, the second quote suggested adding "a recent" to the template description, possibly linking to PD-old may be good. Commander Keane (talk) 03:17, 14 July 2024 (UTC)[reply]

@JWilz12345: Hmm if you refer directly to the image file, the {{NoFoP-Italy}} template is not present, only in the DR. However, it is good to add the {{PD-old-architecture}} template to those photos, to avoid future mistakes. @Commander Keane: Yes, I think it would be good to open some discussion on that. Maybe with that small change, it would avoid inconveniences like the above. Greetings to both of you! --Mazbel (Talk) 03:27, 14 July 2024 (UTC)[reply]

@Mazbel When you make such DRs, could you also please add the relevant category? Otherwise nobody can check your claims and the images get deleted after a week unless somebody casually notice them. Friniate (talk) 16:36, 14 July 2024 (UTC)[reply]

There are stil two delete nominations active. File:Porta Susa old station building 2016 1.jpg and File:Porta Susa old station building 2016 3.jpg.Smiley.toerist (talk) 16:04, 16 July 2024 (UTC)[reply]

(Discussion moved to right place) Any guidance appreciated. --Rlandmann (talk) 10:13, 13 July 2024 (UTC)[reply]

Good luck with it, but this is the page you should be on, with this. Broichmore (talk) 19:47, 13 July 2024 (UTC)[reply]

Many thanks; I'll move it. --Rlandmann (talk) 22:52, 13 July 2024 (UTC)[reply]

At File:Baron Moncheur, F.R. Coudert, W.D. Robbins LCCN2014719398.jpg I get the hidden category when I use {{taken on|August 21, 1917}} but I do not get it when I switch to {{taken on|1917-08-21|location=United States}}. I need the country because there are other countries in the August 21, 1917 category. How do I make the category hidden, like the others? --RAN (talk) 14:24, 13 July 2024 (UTC)[reply]

You can create the category page with the same content as the category for the day before. --Geohakkeri (talk) 15:51, 13 July 2024 (UTC)[reply]

Any protests if i move this to "2024 assassination attempt of Donald Trump"?--Trade (talk) 02:16, 14 July 2024 (UTC)[reply]

Why is it necessary to specify the year? Were there previous assassination attempts on President Trump? Elizium23 (talk) 02:24, 14 July 2024 (UTC)[reply]

It's not necessary at all Trade (talk) 02:29, 14 July 2024 (UTC)[reply]

Perhaps it is too soon, and things are changing rapidly enough. The category name, as it is, isn't inaccurate, so I'm in no hurry to change it. There is still significant variance in the article names in different languages, and there is certainly a large discussion on enwiki to change the name of the main article, as well. Elizium23 (talk) 02:33, 14 July 2024 (UTC)[reply]

It could be useful to see at one glance when an assassination attempt took place --PantheraLeo1359531 😺 (talk) 10:24, 14 July 2024 (UTC)[reply]

It is now at Category:Attempted assassination of Donald Trump in case anyone was interested. Commander Keane (talk) 01:41, 15 July 2024 (UTC)[reply]

• Why was the redirect deleted, it appeared useful. --RAN (talk) 03:32, 15 July 2024 (UTC)[reply]

  Would support --PantheraLeo1359531 😺 (talk) 07:24, 15 July 2024 (UTC)[reply]

I took a CC-BY-SA photo from Commons File:Craignish Rainbow.jpg and cropped it to focus on the landscape rather than the sky which I uploaded as File:Craignish_Landscape,_2017.jpg. OK, there is no problem for me to do this given the original work was CC-BY-SA. But when I was in the licensing screen in the upload wizard, I was able to tick a box to say that I was uploading a work that contained the work of others and that it was a licence accepted on Commons, but nowhere on that screen did I get to say what/where the source was. Surely for both the purposes of licence checking and attribution, I needed to identify the original image. Previously there was a box called (I think) "source" where I would previously have written like "Crop of File:Craignish Rainbow.jpg" enabling the licence to be checked and attributing the original creator of the image. When I came to the next screen (where you name it, describe it, categorise it, etc), I added the "Crop of ..." into the "Other information" box. OK, I think I've done my best to do the right thing by the original creator of the work by doing this, but I feel that most people won't think about doing that without being prompting and, as it relates to licensing, I should it should form part of the previous screen. I think after ticking the box saying it contains the work of others, there should be question(s) to identify what works of others are involved and their licencing. Or am I missing something? Kerry Raymond (talk) 02:31, 14 July 2024 (UTC)[reply]

Pinging @Sannita (WMF). - Jmabel ! talk 05:20, 14 July 2024 (UTC)[reply]

@Kerry Raymond Thanks for the thorough report. I'll open a Phab ticket about it, and see that we address it at the next meeting available. Sannita (WMF) (talk) 08:55, 15 July 2024 (UTC)[reply]

At Category:Charles Darwin we have a family tree. People with Commons Categories get a blue link. But, Josiah Wedgwood does not get a blue link even though he has a category. When I click on the Wikidata link to see why, it takes me to the Russian language version for Josiah Wedgwood at Wikidata. Can anyone figure out why one entry is doing this incorrectly but the others work fine. The template for the family tree was imported from the Russian Wikipedia a few years ago. --RAN (talk) 16:49, 14 July 2024 (UTC)[reply]

The Russian thing was an easy fix. --Geohakkeri (talk) 17:03, 14 July 2024 (UTC)[reply]

• What was the secret? And why still no blue link to the category? --RAN (talk) 03:31, 15 July 2024 (UTC)[reply]

I've added a new response at the bottom of this talk page, maybe it can be worth reading and/or commenting on it if you want. MGeog2022 (talk) 17:50, 14 July 2024 (UTC)[reply]

Pets: Entries • Votes • Scores

Rank	1	2	3
image
Title	Australian Shepherd Dog	Hachi and Boy	Cat enjoying the sun between daisies
Author	Ermell	HachiBoy	Lusi Lindwurm
Score	27	15	13

Waves: Entries • Votes • Scores

Rank	1	2	3
image
Title	This was shot in Kakinada Beach, shows struggle of fishermen in middle of sea	A wave painted with a white neon lamp in a flashlight, city beach in Płock, Poland.	Port Saint-Michel in Batz-sur-Mer
Author	Zahed.zk	Lightpainterplock	Ibex73
Score	28	19	11

Congratulations to Ermell, HachiBoy, Lusi Lindwurm, Zahed.zk, Lightpainterplock and Ibex73. -- Jarekt (talk) 01:19, 15 July 2024 (UTC)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hopefully a super-simple issue, there's a creature - a fly species which the name spelling changed slightly from "Psilota decessa" to "Psilota decessum"

It has two wikidata files now, i think that's what's desirable on there even for such minor name differences - here the last letters of the species name only changes due to some taxonomy mumbo-jumbo [explained on wikispecies]. https://www.wikidata.org/wiki/Q21325248 https://www.wikidata.org/wiki/Q14518044

I'm unfamiliar with wikimedia commons. I think that i've changed it to revised Category:Psilota decessum, but where i think it's calling to "Wikidata Infobox" that's still reflecting the (older, wrong) Psilota decessa from it's wrong wikidata. I've tried changing some links that wikidata end, but what am i missing? In other words, I want that "Wikidata Infobox" to instead be reflecting Q14518044 Sjl197 (talk) 01:07, 16 July 2024 (UTC)[reply]

Heh-heh, "super-simple" heh-heh, famous last words!

Yes, that is indeed arcane mumbo-jumbo about a Latin language declension issue. If I'm understanding this correctly, and this is really a case of "old/deprecated/incorrect" spelling, then I'm not sure we can justify separate Wikidata items. I think we should go over there and propose a merger. It is, however, notable that they carry different taxon IDs at various sites, but hopefully those can be kept in a unified/merged item with appropriate documentation.

If we can't merge them on Wikidata then that may complicate the representation on Commons and other projects. I'd prefer a simple and straightforward process instead. Elizium23 (talk) 01:24, 16 July 2024 (UTC)[reply]

I had Latin as subject in school, and to me, it seems like the Psilota decessa looks better, as the second word complies the concord in "Kasus", "Numerus" and "Genus" --PantheraLeo1359531 😺 (talk) 11:08, 16 July 2024 (UTC)[reply]

I simply assumed that for any specialized field, be it bio-taxonomy or pharmaceuticals, the Latin language has progressed and specialized beyond its actual linguistic roots, and clearly in this case, they're applying extremely arcane and specific rules to it. (The dictionary link indeed went to wikt:decessuum, which indicates that all derivatives use macrons as well, so there are liberties taken.) Elizium23 (talk) 16:31, 16 July 2024 (UTC)[reply]

and yes, when i started looking into the issue a couple of days ago i had the view that "Psilota decessa" seemed a tolerable formation, i.e. per gender agreement between two parts, the genus as feminine and adjectival species name, but yes, biological latin is indeed a derivative, with many extra issues as due any specialist field, even worse this has several hundreds of years of baggage about all that! Sjl197 (talk) 05:07, 17 July 2024 (UTC)[reply]

@Sjl197: The correct name is P. decessa, not P. decessum. When Hutton described it in 1901, he assigned it to the genus Melanostoma. Melanostoma is neuter, so he used the neuter form of the adjective, decessum. When the species was later moved to the genus Psilota, it changed from neuter to feminine (because Psilota is feminine), and the adjective changed with it, to decessa. The invalid form Psilota decessum is a solecism used only by those who do not understand Latin. (The comment on Wikispecies, that decessum is a noun, is wrong: there is no noun with the nominative form decessum. The link there points instead to the form decessuum with two U's, which is the genitive plural form of the noun decessus. All of the changes to P. decessum should be reverted back to P. decessa. Crawdad Blues (talk) 21:24, 16 July 2024 (UTC)[reply]

Editing to add that ICZN 31.2.2, cited on the Wikispecies page, is irrelevant here, because there is no noun with the nominative form decessum that Hutton could have intended. The word must therefore be treated as an adjective. You assert in your rename requests that this word is now treated as an "invariant noun" (on whose authority? no source is cited), but if that were the case, it would be decessus, not decessum. I fear you have expended a lot of effort on a misunderstanding. Crawdad Blues (talk) 22:20, 16 July 2024 (UTC)[reply]

I think Crawdad Blues is entirely correct here. - Jmabel ! talk 04:26, 17 July 2024 (UTC)[reply]

Was @Sjl197 involved in GBIF or iNaturalist changes in some way? Because those sites are both convinced about the decessa -> decessum deprecation. GBIF deleted the taxon in 2016. iNaturalist site bears the same GBIF citation mentioned here. opentreeoflife.org doesn't seem to differentiate them too much. So other than applying a knowledge of Latin declensions (which seems sort like Original Research to me?) does anyone have a reliable secondary source, other than this GBIF thing we're looking at, which clearly documents that decessa is the preferred and modern name? Elizium23 (talk) 04:40, 17 July 2024 (UTC)[reply]

@Crawdad Blues: etc. Well, going back to start, my "super-simple" were apparently indeed famous last words! There's a lot said above Crawdad Blues to indicate good knowledge of "Biological latin" so i'm grateful, but many bold statements which i'm wary about. We agree on the early formation by Hutton, where his Melanostoma decessum does seem perfectly formed as a neuter adjective. That's how I was viewing it a couple of days ago, if so, then recombined with the feminine Psilota would indeed 'simply' give Psilota decessa. To briefly answer @Elizium23, then indeed i'm on iNat also, so involved with changes there. That was my starting point to the whole issue. To my view, there is nothing on iNat that is "convinced about the "decessa -> decessum deprecation", it's got both versions active, which cannot be, i'd only setup so decessum would be preferred, but thats on hold [1]. I wasn't involved in GBIF (where decessa was deleted in 2016), but from other things they do, then i'd say that deletion is not necessarily linked to any informed change, but may be a change in usage on one of their sources, hence I direct you to Systema Dipterorium [2] which GBIF largely takes as the authoritative catalog for that group, and their view feeds into several databases. Point is, there's a bunch of resources that seems to have shifted from "decessa" to "decessum", several done long before i've tried unifying iNaturalist to a single active name, then various Wikis - leading to this discussion.

On the actual nomenclature issue, i'm now seeing that i've misstepped on some editing of the Wikispecies. I had edited the Note: Under ICZN" etc, but i had not created that. It's the only justification i found anywhere about why "Psilota decessum" could be the form to use. Please see under the "Talk" page (same Wikispecies), for a response now from the user who created that text, which i'd modified. He also merged "Psilota decessa" -> "decessum" (also on wikispecies) back in 10 January 2023‎. I'll admit i was wrong about my edit to specify the genitive "decessuum (with two U's). He also points out same. I had misread the genitive in the wiktionary table. Before my very recent edit to that (in hindsight wrong) genitive, his previous wiktionary link was pointing instead to the accursative singular case which DOES read "decessum", i.e., spelt the same way as neuter adjective [https://en.wiktionary.org/wiki/decessum#Latin]. Above is said "(The comment on Wikispecies, that decessum is a noun, is wrong:". I don't agree it says that - it reads "the epithet "decessum" is treated as a noun". Unless you or someone well versed in linguistics can explain why not, to me any case of a noun such as "decessum" is still a noun. As for "You assert in your rename requests that this word is now treated as an "invariant noun (on whose authority? no source is cited)", the Wikispecies already states "Under ICZN Art. 31.2.2". So it's under the authority of that article of the ICZN, i felt that was clear. Here's what that article says: "31.2.2. Where the author of a species-group name did not indicate whether he or she regarded it as a noun or as an adjective, and where it may be regarded as either and the evidence of usage is not decisive, it is to be treated as a noun in apposition to the name of its genus (the original spelling is to be retained, with gender ending unchanged." Now, with that in hand (and admitting i was wrong on the genitive), the crux really is whether "decessum" in the accursative singular would fit with "31.2.2." or not. I'd wrongly switched the Wikispecies wording to specify the genitive plural as i felt other things said by ICZN allow for nouns of species epithets to be in nominative (as said repeatedly above by Crawdad Blues but also allows them as genitives. As the noun spelling is neither nominative nor genitive, i now feel things get murky. Firstly, does the text in "31.2.2" exclude nouns in accursative singular? I'd say that text is ambiguous about cases. Secondly, if for argument sake we accept decessum as a noun, and its accursative case as acceptable, then follow adoption that way, i can't agree when Crawdad Blues said "that would be decessus, not decessum". I'd say "31.2.2" clearly reads that "the original spelling is to be retained, with gender ending unchanged" ergo decessum. Ok, all that said, back to IF decessum were the genitive spelling, i'd hold strong on maintaining it can be treated as a noun and case closed. But now i've realised it's only in accurative singular, then we're into some arcane arguments about interpretation of ICZN wording if err towards decessum - which i'm increasingly seeing as quite tenuous. What's really problematic as a consequence is that decessum is widely adopted in many sources (databases, pulbications etc), and to try to 'kill that' is going to be painful compared to what initially seemed simple to just get a few more of the Wiki stuff inline! What's really awful though is that lawyers get paid vast sums of money to interpret arcane wording in ambiguously worded codes, yet taxonomists just get grief! Sjl197 (talk) 06:36, 17 July 2024 (UTC)[reply]

I'm traveling now and am not very adept at writing on a mobile device (I am not part of the generation that grew up typing with my thumbs!), but I have three comments, which I will try to make as brief as possible:

(1) On the question of whether an accusative noun is permissible in a Latin name, the answer is no. Since Linnaeus Latin binomials have traditionally been given in the nominative form. The names of genera and all higher taxonomic divisions are always nominative. Specific names are almost always nominative, whether they are adjectives (nominative by agreement with the genus name) or nouns (nominative in apposition to the genus name). The only exception is that specific names can also be expressed as genitive modifiers; most of these are proper nouns, the names of places or people, used to describe the range or habitat of a species or the person in whose honor it was named. But as I think everyone here has now acknowledged, decessum is not genitive. And there is absolutely no way in which an accusative noun can be used in apposition to a nominative generic name like Psilota. See ICZN 11.8 and 11.9. This is a dead end.

(2) If, as Sjl197 says, the solecism P. decessum is "out there" in places like iNaturalist, this is probably due to the unfortunate typographical errors in Thompson 2008, which was poorly copyedited and proofread (full ref and link to this article on the Wikispecies page). Thompson writes decessa on pp. 3 and 16, but decessum on pp. 2, 6, and 7. Obviously, these are not both correct, but once the form Psilota decessum crept into the article (an easy slip since Hutton's original name was Melanostoma decessum), it's easy to understand why the error would make its way into user-generated databases like iNat, since most amateur natural historians, and indeed most professional biologists these days, don't have enough training in Latin to see at once that such a name is impossible. (This is not intended to be a dig at you, Sjl; it's just the way things are. Unlike you, I am not a professional biologist, and I'm sure you know way more about the biology of hoverflies than I do, but by your own admission Latin is not your strongest suit.) Is there any evidence that anyone at all used the form P. decessum before the publication of Thompson's article? If not, my guess is that that is where the confusion began. And of course this is a constant problem on the internet: once misinformation starts circulating online, more and more well-meaning people will say, well, it's "out there", so there must be a reason, and they will start trying to come up with possible explanations, as you did. But in this case all of your ingenuity was wasted in defense of a misprint.

(3) User:Elizium23 asks "does anyone have a reliable secondary source ... which clearly documents that decessa is the preferred and modern name?" This question is precisely backward. The real question is, is there any reliable source - by which I mean a peer-reviewed academic publication, not a user-generated online database - to suggest that the name has been officially changed to decessum? I haven't searched exhaustively (again, traveling, mobile, ugh) but I can't find one. But I'll answer Elizium's question anyway, with a strong affirmative. P. decessa is a New Zealand endemic; it appears nowhere else in the world. The principal taxonomic authority for New Zealand biota is the New Zealand Inventory of Biodiversity (NZIB), published beginning in 2009. For P. decessa, see Macfarlane et al., Phylum Arthropoda Subphylum Hexapoda: Protura, springtails, Diplura, and insects. Checklist of New Zealand Hexapoda, in volume 2 of NZIB, which appeared in 2010 (after Thompson's article, so plenty of time for them to take it into account if it needed to be). See also this page at NZOR (the New Zealand Organism Register) for more information. As far as the scientific community of NZ is concerned, the name of this fly is Psilota decessa. That the users of iNat and other such sites may be confused about the name is irrelevant, especially when error is easily explained by the typographical errors in Thompson.

If the malformed name P. decessum is circulating on the internet, the most useful thing that Wikipedia, Wikispecies, and the Commons can do is ignore it and continue to use the official name as published in peer-reviewed academic publications, most authoritatively in the NZIB. There is no benefit in muddying the waters further by perpetuating the confusion that appears in some online databases with user-generated content. I sympathize with Sjl's frustration; I know they made their changes in good faith, in an effort to reconcile the irreconcilable, and I'm sorry to see the effort wasted. But the category and the files that have been changed should be reverted.

Apologies to all if the tone of my earlier remarks was brusque and peremptory: I did not intend to sound as if I was pronouncing the truth ex cathedra. I'll be back home and able to respond to further questions on Friday. Best wishes to all, Crawdad Blues (talk) 16:06, 17 July 2024 (UTC)[reply]

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

We are :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I found a number of images of graphs without sources, and I now wonder if this is permissible on Commons. Two of the files are in use on itwiki, and no sources have been provided there either; if anything, the images themselves appear to be used as sources. So I hope you understand why I feel the need to bring this up.

I've sorted them under Category:Matrimoni religosi e civili (image set) and initiated a discussion at Commons:Categories for discussion/2024/07/Category:Matrimoni religosi e civili (image set). Sinigh (talk) 12:30, 17 July 2024 (UTC)[reply]

Commons is not Wikipedia, it doesn't have sourcing requirements (other than source of origin of the media for copyright reasons). See Project scope/Neutral point of view (mostly). —TheDJ (talk • contribs) 12:51, 17 July 2024 (UTC)[reply]

Add this template to such files: Template:Datasource missing and see Category:Information graphics without data source.

Something really needs to be done (I'm not saying they all should be deleted). I'm most concerned about files without source prominently featured in Wikipedia articles like File:Fertility Map.png or File:Projected Total Births 2020 2025.png. One could start with a GLAMorgan scan for files in that category that are used (the scan should run faster in a month or so) and discuss this on Wikipedia talk pages because it seems like nothing can be done from WMC side. Prototyperspective (talk) 14:56, 17 July 2024 (UTC)[reply]

Thanks! I should have been able to find that template myself. I agree with the current policy, but I think makes sense in cases like these to at least show users and readers that there's no source for the data presented. That too is educationally useful and informative, to say the least. Sinigh (talk) 15:33, 17 July 2024 (UTC)[reply]

That's why the template adds a red-colored infobox below the image. The Problem with that is people don't see it because Wikipedia shows images when clicking on them in a way that doesn't show much info from the WMC page. On Wikipedia, I think the respective image descriptions could be tagged with en:Template:Citation needed or similar templates and the WMC category could be a way to find them. Note that many of these use many different sources combined in one image but these should be specified in the file description and often also as refs where the image is used. Agree with you. Prototyperspective (talk) 15:38, 17 July 2024 (UTC)[reply]

Hi folks!

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

• 
  Oblique view
• 
  Top view

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

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

Hi, Greetings

The winners for Wiki Loves Folklore 2024 is announced!

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

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

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

Thank you,

Wiki Loves Folklore International Team

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

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

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

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

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

Hello everyone,

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

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

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

Individual vote:

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

Affiliates vote:

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

Board of Trustees of the Wikimedia Foundation:

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

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

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

The Charter Electoral Commission,

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

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

Does anyone know of a template or module which would allow me to give it two strings and simply return the one that comes first alphabetically (perhaps with a switch to choose between ascending or descending order)? Josh (talk) 22:24, 18 July 2024 (UTC)[reply]

@Joshbaumgartner: you didn't mention an example application or your level of lua knowledge. {{Sort list}} will kind of do what you need, I am not sure how to only return the first element though. Commander Keane (talk) 12:31, 19 July 2024 (UTC)[reply]

@Commander Keane I am guessing from your response that this isn't something that already exists out there. My Lua knowledge is really nothing to be honest. I've dabbled in tweaking some but with meh results. en:Template:Min does exactly what I want, except that it only works for numbers, and I want to feed it strings. I'm developing a template that will determine a target category name based on various elements, but in some cases the order of the words in the category name are alphabetical. For example, if it has 'children' and 'adult humans', the correct target would be 'adult humans with children', not 'children with adult humans'. Thus, I want a function that allows the template to quickly know which of those two should come first when forming the phrase. Here is my ideal input and output for this case:

• {{Str min|1=children|2=adult humans}} --> adult humans

{{Sort list}} is not useful for this as it returns all of values in a list format. It also requires some unfortunate formatting on the input side as well. I could do a lot of pre-formatting to create the input it needs and then a lot of formatting on the back end to strip it back down to what I need, but that seems like a lot of code to shoehorn in a function that wasn't really intended for purpose. That said, I looked at that before posting here to see if I could maybe modify it, but unfortunately my lack of Lua skills made that effort a failure. I assume for an actual Lua user, it is probably child's play. Josh (talk) 15:29, 19 July 2024 (UTC)[reply]

@Joshbaumgartner I'm currently learning C++ and Python languages, and cannot focus on Lua. I will be writing a Python script on that alphabetical string function at Wikifunctions. Anyone can convert it into Lua if necessary. Sbb1413 (he) (talk • contribs • uploads) 18:19, 19 July 2024 (UTC)[reply]

Finally created the Python function at Z18069. Anyone with a skill in Lua can convert it into the desired language. Sbb1413 (he) (talk • contribs • uploads) 18:44, 19 July 2024 (UTC)[reply]

I have tried to do it myself at Module:Two strings to alphabetically first string but failed. Sbb1413 (he) (talk • contribs • uploads) 19:04, 19 July 2024 (UTC)[reply]

{{#invoke:Two strings to alphabetically first string|main|children|adult humans}} —> adult humans --Geohakkeri (talk) 21:49, 19 July 2024 (UTC)[reply]

Thank you for implementing the function in Lua. @Joshbaumgartner use this module. Sbb1413 (he) (talk • contribs • uploads) 02:48, 20 July 2024 (UTC)[reply]

Thanks, both of you. Those little things catch me when I try and dabble and I don't know enough to fix them. I'm not sure what 'main' does, but I know it works now. I was testing it while you posted this. Josh (talk) 02:53, 20 July 2024 (UTC)[reply]

@Commander Keane, @Sbb1413, @Geohakkeri: Thanks for all of the input, it looks like Geohakkeri got it working. I've created {{Str min}} which invokes the module Sbb1413 and Geohakkeri worked on. Josh (talk) 02:51, 20 July 2024 (UTC)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hello everyone.

I recently decided to change the license of all the photographs taken by me that I have uploaded to Wikimedia Commons, which are located in this category, to the Creative Commons CC0 1.0 Universal Public Domain Dedication license. Would there be a way to change the licenses for these files globally, or is it only possible individually?

Thank you in advance. P4K1T0 (talk) 20:43, 19 July 2024 (UTC)[reply]

Though it is technically relatively easy with VFC or with a bot, read Commons:License revocation, please. What you could do as the creator is adding the license tag {{cc-zero}} or as you did before {{self|cc-zero}}. I or someone else could even do it for you referring to your request here. It would be in my opinion better, though, if you’d write some lines on your user page which could then be linked in the edit comment. — Speravir – 00:20, 20 July 2024 (UTC)[reply]

I just wrote this comment on my user page. Would it be valid like that? Thank you. — P4K1T0 (talk) 09:25, 20 July 2024 (UTC)[reply]

Yes, that will do.

@Speravir: if you are following up on this, please make sure things like File:1927, La Asamblea Nacional, Alfonso Torres López.jpg are left alone. - Jmabel ! talk 15:58, 20 July 2024 (UTC)[reply]

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

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

Greetings, regarding:

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

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

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

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

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

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

• I am not sure what deletion criteria to use, and I'm hesitant to start a deletion discussion yet before we've gauged consensus and established a concrete rationale for that. So, thoughts? Elizium23 (talk) 21:29, 20 July 2024 (UTC)[reply]