Commons:Village pump

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Shortcut: COM:VP

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
🌐 Village pumps for other languages
COMMONS DISCUSSION PAGES (index)
Welcome to the Village pump

This page is used for discussions of the operations, technical issues, and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Archive/2024/07.

Please note:

  1. If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing, please do not comment here. It is probably pointless. One of Wikimedia Commons’ core principles is: "Only free content is allowed." This is a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias.
  2. Have you read our FAQ?
  3. For changing the name of a file, see Commons:File renaming.
  4. Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer).
  5. Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam.

Purposes which do not meet the scope of this page:

Search archives:

   

Start a new discussion

# 💭 Title 💬 👥 🙋 Last editor 🕒 (UTC)
1 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 Works of art of men smoking (activity) 4 4 ReneeWrites 2024-07-19 05:53
4 What are free media resources for illustrations? 2 1 Prototyperspective 2024-07-20 19:30
5 Psilota decessa -> Psilota decessum 11 5 Crawdad Blues 2024-07-17 16:06
6 Oak Island's map 5 2 Tylwyth Eldar 2024-07-19 05:26
7 Category:Flickr streams/Category:Photographs by Flickr photographer 9 5 Prototyperspective 2024-07-19 11:11
8 Unsourced data on Commons? 6 3 Sinigh 2024-07-23 19:50
9 Mysterious Intel microprocessor/IC 2 2 Glrx 2024-07-18 04:09
10 Results of Wiki Loves Folklore 2024 is out! 1 1 Rockpeterson 2024-07-18 08:25
11 empty sub-categories of Category:EuroGames_2024_Vienna 1 1 Zblace 2024-07-18 10:11
12 Book covers' copyright 2 2 Geohakkeri 2024-07-18 10:44
13 Wikimedia Movement Charter ratification voting results 1 1 MediaWiki message delivery 2024-07-18 17:51
14 Freedom of panorama for photos taken across the border 4 3 A1Cafel 2024-07-19 05:59
15 Glitch 3 3 Speravir 2024-07-19 23:57
16 Video question 4 2 PantheraLeo1359531 2024-07-19 19:08
17 Pre-implementation discussion on cross-wiki upload restriction 9 4 George Ho 2024-07-21 22:14
18 Croptool 3 2 Seth Whales 2024-07-21 05:00
19 Political donation from Thomas Crooks - public record image 5 5 B25es 2024-07-22 06:33
20 Error during upload 5 3 Palu 2024-07-21 11:31
21 What are outgoing and incoming wikilinks? 4 2 Jmabel 2024-07-23 19:13
22 Appropiate mother-cats🐈 for Category:Intel 8286 3 2 PantheraLeo1359531 2024-07-21 13:48
23 Extracted file deleted 3 2 Kakan spelar 2024-07-21 19:44
24 Commons Impact Metrics now available via data dumps and API 1 1 Sannita (WMF) 2024-07-22 14:11
25 Adding an artist to an image within Wikidata 7 3 Broichmore 2024-07-23 09:13
26 Location 6 4 Smiley.toerist 2024-07-23 08:13
27 Should documentation start recommending AV1 over VP9? 3 2 Snowmanonahoe 2024-07-23 19:33
28 Overlapping templates 1 1 Trade 2024-07-23 03:19
29 Category:Videos by subject 2 2 ReneeWrites 2024-07-23 09:40
30 Task — Wikimedia logos categorisation 1 1 JnpoJuwan 2024-07-23 21:01
31 Managing overpopulated categories 3 2 Sinigh 2024-07-24 02:15
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.
Village pump in Diepenheim, Netherlands, being packed in straw to prevent freezing (1950) [add]
Centralized discussion
See also: Village pump/Proposals   ■ Archive
Template: View   ■ Discuss    ■ Edit   ■ Watch
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days.

July 05

German currency files without machine-readable license

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

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:
--Jarekt (talk) 23:52, 19 July 2024 (UTC)[reply]

July 06

POTY (Picture of the Year) competition needs help!

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

Check out the discussion here. Shawnqual (talk) 04:46, 6 July 2024 (UTC)[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]

July 15

Works of art of men smoking (activity)

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

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

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

Why can't there be both, is that such a deal breaker? Broichmore (talk) 16:16, 15 July 2024 (UTC)[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]

What are free media resources for illustrations?

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

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

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

July 16

Psilota decessa -> Psilota decessum

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]

Oak Island's map

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

We are :
  • Smith’s Cove = south
  • Sheerdam Cove = east
  • Sellars Cove = north
These names are included on recent maps found on the web. But when we look for old plans, or in books about the island (page 7), we find:
  • Smith’s Cove = east
  • South Shore Cove = south
  • Joudrey’s Cove = north
Which version is correct? Thanks, Sincerely --Tylwyth Eldar (talk) 15:43, 16 July 2024 (UTC)[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]

July 17

Category:Flickr streams/Category:Photographs by Flickr photographer

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

Unsourced data on Commons?

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]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Sinigh (talk) 19:50, 23 July 2024 (UTC)

Mysterious Intel microprocessor/IC

Hi folks!

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

  • Oblique view
    Oblique view
  • Top 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]

July 18

Results of Wiki Loves Folklore 2024 is out!

Hi, Greetings

The winners for Wiki Loves Folklore 2024 is announced!

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

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

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

Thank you,

Wiki Loves Folklore International Team

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

empty sub-categories of Category:EuroGames_2024_Vienna

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

Wikimedia Movement Charter ratification voting results

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

Hello everyone,

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

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

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

Individual vote:

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

Affiliates vote:

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

Board of Trustees of the Wikimedia Foundation:

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

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

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

The Charter Electoral Commission,

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

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

Freedom of panorama for photos taken across the border

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

July 19

Glitch

Tracked in Phabricator
Task T370304

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

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

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

Video question

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

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

Pre-implementation discussion on cross-wiki upload restriction

Tracked in Phabricator
Task T370598

The proposal to restrict non-autoconfirmed users from using cross-wiki upload tools has received unanimous support so far, despite proposer's attempts to withdraw the proposal. Do I need to notify all wikis at Tech News or something? Actually, I'm thinking about writing a Phabricator task requesting implementation of such restriction. Furthermore, I'm unsure whether re-proposing this at Meta-wiki is necessary. George Ho (talk) 07:05, 19 July 2024 (UTC)[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]
Can you suggest an example of the warning text? Will it be clear if the user is allowed to upload or not, and where is the workaround if they are not allowed to proceed? (Something along the lines of "Click here (link), and if it says ___ you cannot upload", "You can still upload if you go to ___"?) Note that not every average user understands what "autoconfirmed" means, or how their centralauth-connected accounts work. I think many will be surprised to see they have "new" Commons accounts when they have contributed to Wikipedia for a long time. whym (talk) 01:36, 21 July 2024 (UTC)[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]
This phab ticket has been made: phab:T370598. --George Ho (talk) 22:14, 21 July 2024 (UTC)[reply]

July 20

Croptool

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

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

Political donation from Thomas Crooks - public record image

Greetings, regarding:

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]
    • I can't see the relevance of the fact that en-wiki does not generally allow primary sources as citations. Commons consists overwhelmingly of primary-source material.
    • It is no more being "h[e]ld up and say[ing] 'look look'" than any other image on Commons.
    • In short, I can't imagine any reason to delete it. How are you saying it differs from, for example, Lee Harvey Oswald's Social Security card, which we have hosted for over a decade? - Jmabel ! talk 22:08, 20 July 2024 (UTC)[reply]
Enwiki's policies aren't very relevant for what is and isn't allowed to be hosted on Commons. Commons is mostly concerned with whether images are within the scope of their own project, and whether these media files are freely licensed (you can read about the project scope more here: COM:SCOPE). Images of Thomas Crooks uploaded to Commons were probably deleted for not being released under a free license.
Considering this image is in the public domain, you could only argue it being out of scope to have it deleted, but considering the widespread use it sees across various wikiprojects (not just the English-language one) I don't think you'll have much success there. You could argue for it to be taken down from the enwiki page specifically for being a primary source, but you'd have to make that case there. ReneeWrites (talk) 07:39, 21 July 2024 (UTC)[reply]
@Elizium23, Jmabel, and ReneeWrites: I nominated the pdf file for deletion. Regarding the second image, I agree with ReneeWrites. Since it is in use in several articles, it is clearly in scope and there is no valid reason to delete. SCP-2000 15:24, 21 July 2024 (UTC)[reply]
I've seen both files and I find them very interesting. I didn't know how political donations in the US looked like (and I don't know if there is any form like that in Spain). So -beyond the shooting and all that- is formative, it improves my knowledge, and therefore I think it's worth being in Commons. Maybe an empty form would be better. But as for now, that one works. B25es (talk) 06:33, 22 July 2024 (UTC)[reply]

July 21

Error during upload

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

@Palu: just copy-paste the wikitext from a file page for another of your uploads and edit accordingly. No one can do this for you, because only you can grant the license. - Jmabel ! talk 03:08, 21 July 2024 (UTC)[reply]
No, editation is not possible due to error: "In order to edit the page, you must first load the file." Palu (talk) 08:57, 21 July 2024 (UTC)[reply]
There was some bug but I was able to create the pages. Now you can add the correct content. GPSLeo (talk) 09:16, 21 July 2024 (UTC)[reply]
Thank you, now worked perfectly, done. --Palu (talk) 11:31, 21 July 2024 (UTC)[reply]

What are outgoing and incoming wikilinks?

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

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

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

I think on Commons these are not a problem. We don't particularly interlink our galleries. Of course, on other wikis where the analogous space is "article space", the same thing would represent a problem. - Jmabel ! talk 19:17, 21 July 2024 (UTC)[reply]
@Jmabel: Thank for your reaction. Next question: are these two Special pages still needed on Commons? JopkeB (talk) 04:55, 23 July 2024 (UTC)[reply]
I see no purpose for them. - Jmabel ! talk 19:13, 23 July 2024 (UTC)[reply]

Appropiate mother-cats🐈 for Category:Intel 8286

Hi!

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

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

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

Extracted file deleted

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

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

@Kakan spelar: I don't see what here calls for a general discussion. Is anything stopping you from nominating it for deletion? - Jmabel ! talk 19:19, 21 July 2024 (UTC)[reply]
@Jmabel: No not really, just wanted to know if this was a mistake or why it was still up. I guess I'll nominate it for deletion then. // Kakan spelar (talk) 19:44, 21 July 2024 (UTC)[reply]

July 22

Commons Impact Metrics now available via data dumps and API

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

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

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

Adding an artist to an image within Wikidata

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

@Cryptic-waveform: : your template, so you can presumably answer better than anyone else. - Jmabel ! talk 17:24, 22 July 2024 (UTC)[reply]
It looks to me like author = {{various}} is hardcoded in the template with no override possible, which I think should not be the case. - Jmabel ! talk 17:25, 22 July 2024 (UTC)[reply]
Hello. First of all I've only modified the file to use a more general template rather than a template-by-year, to remove duplicate code and differences between templates. Additionally I've also extensively documented the template.
As for the question of why, there are a lot of benefits to the current approach. It ensures that all files looks similar, link to previous and next page, and automatically link extracted images.
@Broichmore: : What change are you trying to make? I can look into making it possible. Cryptic-waveform (talk) 20:06, 22 July 2024 (UTC)[reply]
Small questions, potentially big answers.
I'm concerned with images, rather than pages.
Most of these points are covered in the existing artwork template.
Regarding engravings, We, would want to include for, the engraver/etcher, the artist of the intermediate drawing, and the author of the original sketch, photographer, painter, or sculptor.
We would want to include for caption (title), ability to augment the description. Adding translations of same.
Perhaps, issue number, page number, volume number.
Expanding on the date, if known.
Adding in depicted place or people? Place of creation? Credit line?
Flexibility on choice of License?
As to the benefits? The artwork template already makes one file look similar to another, and automatically links extracted images.
I understand? your idea for the use of templates. However, in the long term, what we need to do is have choice of license linked in some way to last or most appropiate creator. Wikidata could do that, because it contains death date, citizenship, and workplace. Broichmore (talk) 08:44, 23 July 2024 (UTC)[reply]
The Gartenlube, has drifted away, from how we treat newspapers of this era on the project. One thing thats needs cleaning up, is this page, and how the all date cats on it are sorted. See 1920 in particular. Can you fix?
Already Gartenlaube images suffer from very little or no content development. It's not a place for casual visitors. It's very niche, only really accessible to editors with a German background and language, and we don’t have enough of them. It's use of gothic script, and the way that artists and engravers signed work their work, makes for highly specialized work.
French periodicals, suffer from a similar lack of interested contributors, only they don’t use a difficult typeface, and they don’t have the added handicap, IMO of being Wikidata centric. Broichmore (talk) 09:10, 23 July 2024 (UTC)[reply]
To sum up, the kind of people, who can easily read the text and identify the artists are not the kind of people, that relate to, or want to be tied up in wikidata. Broichmore (talk) 09:13, 23 July 2024 (UTC)[reply]

Location

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

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

These are MTR C-stock trains in Hong Kong. I've categorized and edited descriptions appropriately. Pi.1415926535 (talk) 20:53, 22 July 2024 (UTC)[reply]
(edit conflict) As a wild guess, C Train might refer to TML C-train. --Geohakkeri (talk) 20:54, 22 July 2024 (UTC)[reply]
I don't undertand why? Every room has a floor. Train seating is more descriptive here than floor. There was nothing wrong with Category:Train interiors. Broichmore (talk) 07:44, 23 July 2024 (UTC)[reply]
The floor category is only for images where the floor is prominent such as File:Osaka metro floor 2024.jpg. I draw the line at showing substantial amount of floor. There are also images showing no floor but the roof File:Chichibu Railway 7000 series interiors 1.jpg Smiley.toerist (talk) 08:13, 23 July 2024 (UTC)[reply]

July 23

Should documentation start recommending AV1 over VP9?

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

References

  1. ↑ I'm not sure how authoritative the MDN web docs are on the topic? Scroll down a bit, and they recommend encoding videos with fast presets to reduce the compression. That's not accurate... for those not in the know, a slower encoding preset trades off encoding time for file size, not quality.
Is it also well usable in FFMPEG? My last level of knowledge is that it is in an experimental phase. I think this would be an important parameter, when working with AV1 --PantheraLeo1359531 😺 (talk) 13:14, 23 July 2024 (UTC)[reply]
I've never seen anything that indicates that AV1 support is experimental. I doubt that's still the case as it's been around for six years at this point. Snowmanonahoe (talk) 19:33, 23 July 2024 (UTC)[reply]

Overlapping templates

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

Category:Videos by subject

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

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

Task — Wikimedia logos categorisation

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

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

Wikimedia logos by language‎ (13 C)

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

Managing overpopulated categories

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

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

@Sinigh: Can you give any examples of these categories? That would make it easier to discuss what to do. In most cases, subdividing by date is not the most useful; it's better to subdivide by subject. Pi.1415926535 (talk) 23:20, 23 July 2024 (UTC)[reply]
@Pi.1415926535: Yes, "by subject" is of course the most useful one. Here are a few different examples:
Since images have dates and are in other categories that define their subjects, I'm essentially wondering if this could somehow be used to make sorting easier. Bit of a vague question and a long shot. Sinigh (talk) 02:15, 24 July 2024 (UTC)[reply]

July 24

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