Call statistics - Pageviews Analysis

In the German Wikipedia there is a link in the footer for the retrieval statistics. I would like to see this for all pages on Commons as well. (Example (de.wp), Example (Commons User Pages)) (see also) Molgreen (talk) 15:43, 13 April 2025 (UTC)

I think that's already sort of available? Maybe you need to activate it somewhere in settings or gadgets, but I have a link called "Page information" in the right sidebar which leads to this page, and at the bottom of that page in the section "Information on external/private servers", there's a link to page analytics. Nakonana (talk) 16:46, 13 April 2025 (UTC)

I don't know if that's the issue but the right sidebar is not available on mobile or is it? Prototyperspective (talk) 17:07, 13 April 2025 (UTC)

On mobile, there are three vertical dots next to the pencil symbol for editing. If you click those dots, you'll see the link to "Page information" (unless that's something you need to activate in your settings). Nakonana (talk) 17:11, 13 April 2025 (UTC)

Clarification: "on mobile browser". The situation might be different on the mobile app. Nakonana (talk) 17:13, 13 April 2025 (UTC)

There are no vertical dots next to the pencil symbol for editing for me when using Android or am I missing something? Maybe a screenshot would help. Prototyperspective (talk) 18:12, 13 April 2025 (UTC)

File:Screenshot of tools menu on Wiki Commons in mobile Firefox browser.png. I'm using the Vector (2022) skin, if that's relevant. It might be a gadget (maybe MoreMenu or ExtraTabs2) that you need to activate in your settings to see the dots. Nakonana (talk) 18:32, 13 April 2025 (UTC)

I don't see that button. Thanks for the screenshot. Does it also display if you're logged out? Most visitors of Commons on mobile aren't logged in. Prototyperspective (talk) 18:40, 13 April 2025 (UTC)

No, it's not there when logged out. Nakonana (talk) 19:00, 13 April 2025 (UTC)

Do we need a policy against AI generated comments in discussions

Recently the number of comments in discussions they are generated using AI tools dramatically increased. I want to discuss if we need a policy against this. The main reason against such comments from my view is that they make the comments unnecessarily long and it is often unclear if the person who posted the comment really understands what they wrote. In many cases the reason for using such tool might be the insufficient knowledge of English language. Therefore I would suggest that we encourage people writing in their native language if they are not comfortable with English and then the user reading the comment can use a tool to translate the comment knowing that and how it was translated. GPSLeo (talk) 17:48, 13 April 2025 (UTC)

I also think they shouldn't be used for that purpose but comments in discussions they are generated using AI tools dramatically increased I've never seen just one. Prototyperspective (talk) 18:13, 13 April 2025 (UTC)

@GPSLeo: I certainly often use translation tools myself at times to get a first draft when replying to a question in a language such as Portuguese, where (having near-fluent Spanish) I read it well, but write it poorly and (especially) tediously. I almost always find myself editing the AI output before posting, and I certainly understand quite well what I post. I wouldn't want a policy that said I should not do this.

That said, I agree that people should not post machine translations that they cannot even read, especially without also posting the original.

@Prototyperspective: I don't get what you mean to say by I've never seen just one. Meaning, anywhere you've seen one you've seen several (my initial understanding, but not sure why that would be worth your remarking), or something else? - Jmabel ! talk 20:16, 13 April 2025 (UTC)

I don't think the user was talking about posts using machine translation but rather chatGPT, if that's not the case it could be clearer and is using faulty terminology. And I meant I haven't even seen one such post here, at least none that was not quickly removed as offtopic/vandalism. Prototyperspective (talk) 20:51, 13 April 2025 (UTC)

I think it should be a guideline, but not policy to write in your native language rather than chatgpt responses. There is a lot of nuance in user conduct discussions, and a single mistranslation could be the difference between a contributor in good standing and a block for personal attacks. All the Best -- Chuck ^Talk 21:02, 13 April 2025 (UTC)

Just for clarification: I used the word policy not in the sense of a Commons policy but as a synonym for rule. I also think it does not need a new page of this but we could add this to an existing policy/guideline. GPSLeo (talk) 10:42, 14 April 2025 (UTC)

"AI" is a bit of a buzzword but I think we are talking about a ChatGPT scenario over a Google Translate one, both use AI to some extent I guess. For ChatGPT I asked it Generate a keep vote for a Wikimedia Commons file deletion discussion and its first output was Keep – The file appears to be within Commons' scope and meets the relevant licensing and sourcing requirements. It provides educational or historical value and contributes to the understanding of the subject. Unless clear copyright issues or COM:SCOPE violations are present, there's no strong reason for deletion. If used, this is a problem and it should be discouraged. Trying in your best in any language at any skill level is much preffered. Commander Keane (talk) 09:24, 14 April 2025 (UTC)

•  Comment If necessary we have also the possibility to mention it as a subsection of existing policies/guidelines, e.g. we could talk about that in Commons:What Commons is not. However I tend to be opposed because a potential issue is the lacks of potential evidence that a text have been AI generated. E.g. myself I write "so badly" that I can not image that one think my text have been AI generated, however if in a good day I write a very good sentence who will be competent to affirm my sentence have been AI generated and on what criteria? it can even be an open door to some additional disputes. Each user is responsible of their edit and of the content they add, AI generated or not, uncivility and copyright issues aside, that sound fine and sufficiant to me. Christian Ferrer ^(talk) 11:51, 14 April 2025 (UTC)

  I suggest moving Commons:Talk page guidelines to Commons:Discussion guidelines and making a note in the Communication good practice section that says: "You should avoid adding tool-assisted comments from services like ChatGPT, and declare when you do. Native language and understanding is fine." Commander Keane (talk) 08:38, 15 April 2025 (UTC)

  It sounds good to me. Christian Ferrer ^(talk) 11:31, 15 April 2025 (UTC)

Beim letzten Satz beißt sich die Katze doch in den Schwanz. Ich selbst benutze häufig deepl oder halt google, um englisch zu formulieren. Englisch lesen ist idR kein großes Problem, Schreiben jedoch sehr, insbesondere, wenn es in der Diskussion über rein technische Aspekte hinausgeht. Lasse ich den automagischen Übersetzer werkeln, bin ich durchaus in der Lage, das Ergebnis zu kontrollieren und Quatschübersetzungen zu korrigieren. Schreibe ich, wie jetzt ganz absichtlich, deutsch, kann ich mich denn darauf verlassen, dass mich der geneigte Leser per Übersetzungstool richtig versteht? Smial (talk) 11:48, 15 April 2025 (UTC)

Yes ;-) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:27, 15 April 2025 (UTC)

The translation by Google did even get the idiomatic cat biting in its tail and made the fitting "catch-22" from it. Nevertheless, I'll still mostly stick to the local Lingua franca English, even though I'm German, too. Regards, Grand-Duc (talk) 12:30, 15 April 2025 (UTC)

I think the key is to write in a language where you at least can be confident what you are saying!

FWIW, on Help desk especially, if I am reasonably sure I can provide a useful answer in the language of the questioner, I'm going to try to do that. - Jmabel ! talk 18:02, 15 April 2025 (UTC)

Clarity of "Threshold of Originality" and "Freedom of Panorama" in architecture

Clarity is needed around the interaction between the principle of Threshold of originality and Freedom of panorama in the area of architecture. The two principles can be in conflict. Editors need certainty. The architecture section of the ToO in particular needs attention. It consists of nothing but 10 images. The only guide offered is "Images which have been kept because of lack of originality or de minimis". One is left to guess which of the 10 images are covered by de minimis (half of them?) and which by "lack of originality". Why is de minimis even involved here? An architectural image can be (A) de minimis and "original", (B) de minimis and "lacking originality", (C) not de minimis and "original", (D) not de minimis and "lacking originality". Each of these four possibilities needs a rule: must be deleted / may be kept. Then there is FoP Situation in different countries. These rules make no reference to ToO at all. What is the interplay between the two? If, for example, the rule in Azerbaijan says that there is no FoP and the it is "Not OK, non-commercial only", then an editor should be able to rely on that clear, unambiguous guide. Instead, it would appear that the NoFoP/Az rule rule may be trumped by ToO if the building "lacks originality". Is that indeed the case? If so, why does FoP/Az not draw attention to that exemption to the general FoP rule and give examples of how it is to be implemented? Finally, who is the arbiter of "originality"? It all seems highly subjective and not at all helpful to editors. Laurel Lodged (talk) 12:58, 21 April 2025 (UTC)

For more examples (and to see the argumentation for keeping/deleting particular images) you can also check out Category:FOP-related deletion requests/kept, Category:FOP-related deletion requests/undeleted, Category:FOP-related deletion requests/deleted, as well as Category:Threshold of originality-related deletion requests/kept, Category:Threshold of originality-related deletion requests/withdrawn, Category:Threshold of originality-related deletion requests/undeleted and Category:Threshold of originality-related deletion requests/deleted. It will still all be subjective, though, because we can't look into the judges' heads who decide on such cases irl. (And even the judges will make subjective judgments in some way; even if backed up with particular law-based argumentation, they still have to weigh which law would be more relevant for a particular case due its particular circumstances.) Nakonana (talk) 13:21, 21 April 2025 (UTC)

This is not a proposal. Please take this to the corresponding talk pages or COM:VPC. --AFBorchert (talk) 14:51, 21 April 2025 (UTC)

Done Laurel Lodged (talk) 19:22, 21 April 2025 (UTC)

Some broader questions

I am not sure how we can even determine whether de minimis content should be marked when we don't seem even to have consensus on what is the purpose of SDC "depicts".

When "depicts" was introduced, I asked some questions that were never answered. I'm not going to reiterate them all here, but here are some that I think are crucial if we are going to clarify policy:

• What is the purpose of "depicts"? Is it for search by humans? Is it to train AI? Something else?
• Are end users intended to be able to reasonably skim the "depicts" for a given file, or is it basically data written by human editors for the benefit of tools (presumably including search tools), and any value to end users is expected to be via those tools?
• How does the goal of "depicts" (as against its technology) differ from the goal of categories?

A further remark: if we really do want "depicts" tags at various levels of specificity for the same object, then the human effort involved in tagging multiple items up the "instance-of" and "subclass-of" hierarchy seems to me to be wildly disproportionate to the effort involved in stating rules about what tagging of this sort we would want done and having a bot do the tagging. - Jmabel ! talk 19:51, 2 April 2025 (UTC)

When invented the idea for depicts statement was to work the same as categories as they where invented to replace categories. I think this should still be our long term plan and therefore we should use them as we are currently using categories. GPSLeo (talk) 20:08, 2 April 2025 (UTC)

"I think this should still be our long term plan and therefore we should use them as we are currently using categories" The problem is that it's extremely tedious to setup due to the amount of subcategories that Commons have developed over the years

Not to long ago i had to waste 20min simply to copy paste the various subcategories to AC/DC and even then i still had to wait longer for the tool to slowly load the images before i could even start it Trade (talk) 04:45, 3 April 2025 (UTC)

It's also very important to understand that Structured data on Commons does not function like the Commons category system, currently does not intend to, and it does not have the same clear hierarchy and division.

https://commons.wikimedia.org/wiki/Commons:Structured_data/Modeling/Depiction#Level_of_detail Jerimee (talk) 14:18, 3 April 2025 (UTC)

Jmabel asked three questions about SDC depicts. They are good questions. I thought I might hazard hesitant answers.

1. To indicate what objects are present in a general literal sense. Depicts is a visual metaphor, and for image files the meaning is straightforward: what can plainly be seen in its typical form. As if one were to describe the contents to a person without sight in a formal setting (Heinlein's Fair Witness). Abstract concepts such as "admiration" and "order" are permitted, but to be used sparingly, typically with qualifiers, and only when exceptionally prominent. Objects that can be inferred but are not present should not be listed; an audio file of a car horn depicts horn, alarm, signal, but not vehicle. Trivial "I Spy" type depiction statements of objects clearly visible are not forbidden. Constraints on what is permitted for depicts (P180) should require consensus, documentation, and a waiting or transition period — so as not to disrupt or discourage SDC contributors and SDC tools. The goal is to advance human understanding via tools (library science).
2. Both. But more via tools. Human readability is desirable. But this is a specialized system of notation; unfamiliar users will not be able to skim it.
3. Structure is a form of accessibility and provides a myriad of benefits. Our category system is merely a form of hierarchical free tagging, right? depicts (P180) is part of SDC, and the goal of SDC is data retrieval, data aggregation, and data manipulation. If nothing else, SDC differs from categories in that the structure is defined in a formal manner. Those formal definitions help us better cooperate such that our contributions are more generally useful for everybody.

Notes: This reply could be improved with formatting; sorry about that. These answers are my opinion, and are meant to encourage others and are not meant to dispute. SDC is useless without consensus; I care more about guidelines being established than the particulars of the guidelines. I edited this reply.

--Jerimee (talk) 16:46, 3 April 2025 (UTC)

categories have one fundamental problem: it's unclear how that category is related to the image (let's simplify our discussion to just image here without considering all other types).

when i tag something Category:Musée du Louvre, it could mean, the image:

1. is a photo of Musée du Louvre
2. is taken inside Musée du Louvre
3. is a view of somewhere else from Musée du Louvre
4. is produced by Musée du Louvre
5. is owned by Musée du Louvre
6. is sourced from Musée du Louvre
7. depicts an exhibition (anywhere in the world) of items in the collection of Musée du Louvre

...

my understanding is that sdc is to solve this problem, by specifying how exactly a wd item, or any value, is associated with the file.

now we set "statements", which is usually property Pxxx = item Qxxx (or a non-item value) for file Mxxx.

this makes the relation clearer, which has two uses:

1. by becoming better machine readable, it enables easier data analysis (mining, big data, whatever)
2. also because of that, weak AI or strong AI can understand and use the files more easily.

depicts, is the #1 relation listed above. RoyZuo (talk) 18:27, 5 April 2025 (UTC)

it's unclear how that category is related to the image That's not true in the sense or to the extent that you claim. Usually it's clear by how the category is named (or at least/sometimes by the chain of categories). For example, a file in Category:Moon from Earth is a file showing the Moon from the Earth (could technically be a photo or an artwork depending on the cats above but these can be subcateogized or filtered accordingly via the deepcategory in the search).

when i tag something Category:Musée du Louvre, it could mean, the image usually there are subcategories and if not, you can create them. Also this is partly an advantage, don't just look for downsides – this is actually useful if you were looking for files. Moreover, SD also aren't unambiguous – just maybe a bit lesser so if they were used as intended and actually used (especially the latter is not the case) – e.g. it can be a photo or drawing. Also there are many categories for which is there no SD item. But the take-away is: what you said can also be solved via subcategories. Moreover, machines may use this but humans can't really since there are nothing like category pages (which btw is a further reason the SD are so incomplete and full of false data) and categories are also machine-readable and queryable. Maybe SD have some unique applications and uses but then I think they'd better be set via machine vision making use of the categories to detect what is actually depicted, making them far more reliable, accurate, and complete. Even then I wouldn't see it as replacement of categories and just about making what is in the categories more selective for machines and scripts. Prototyperspective (talk) 18:41, 5 April 2025 (UTC)

If the files have the relevant SDC properties - a big "if" - many categories could be replaced with a saved search. For example Illustrations by John R. Neill could be defined/retrieved as either

instance of (P31) → illustration (Q178659)
AND
illustrator (P110) → John R. Neill (Q45111)

or perhaps

instance of (P31) → book illustration (Q998555) OR instance of (P31) → illustration (Q178659)
AND
illustrator (P110) → John R. Neill (Q45111) OR creator (P170) → John R. Neill (Q45111)

More (amateurish) examples at User:Jerimee/search_links, and doc at https://www.mediawiki.org/wiki/Help:Extension:WikibaseCirrusSearch Jerimee (talk) 20:44, 5 April 2025 (UTC)

Interesting but only addresses one part – and then it's not yet like category pages and only something that could be used for such if something was built. Prototyperspective (talk) 22:58, 5 April 2025 (UTC)

category is often a worse method for these purposes than sdc.

• M09-5-003-001 周樹人退学の件清国留学生監督処より通知（復原）.jpg
• M09-5-003-002 周樹人退学の件清国留学生監督処への回答（復原）.jpg

these two letters, one is written by someone and the other is addressed to that person. i am certainly not creating subcats to record this nuance. RoyZuo (talk) 16:38, 25 April 2025 (UTC)

what Roy said! Jerimee (talk) 18:12, 25 April 2025 (UTC)

excellent - what Roy said Jerimee (talk) 20:22, 5 April 2025 (UTC)

I request SVG containing xhtml element can be uploaded

Hello,

I work since 3 days to improve chi2 graphes without using Javascript because commoms refuses upload of SVG containing JavaScript.

I have found a solution based on CSS and input tag of xhtml but commons refuses to upload this SVG because it contains "http://www.w3.org/1999/xhtml" namespace !!!

In FAQ I found some explanations indicating that this namespace is not accepted in SVG without saying WHY !

First of all, xhtml is accepted in SVG, it is only refuse by Commons Wikipedia not by SVG.

Can this restriction for xhtml in SVG be removed to allow great improvements in graphes design ?

You can find improved SVG file on https://github.com/schlebe/SVG-Images/blob/main/Chi-square_Density.svg

I added <input> CheckBox to hide/show some curves and to hide/show some points on curves.

Can Wikipedia improve this situation ?

Best regards

Schlebe (talk) 18:50, 9 April 2025 (UTC)

No, and it's for essentially the same reason - the XHTML namespace includes elements and attributes like <script> or onclick="…" which can be used to execute scripting content. While I'm sure you have good intentions, scripting content (even in SVGs) presents a risk to users; we can't allow it to be included in files. Omphalographer (talk) 23:05, 9 April 2025 (UTC)

Just for information, my SVG file doesn't contain <script> or any other events using script. My SVG contains only <div> and <input> html tags !

I understand your explanation but I don't understand the second NO that indicate that it is impossible for Wikipedia to improve this situation.

It's just a matter of willpower !

Wikipedia can certainly check if uploaded file contains script code or prohibited html tags and accept all files that are conform to check process ! Schlebe (talk) 08:19, 17 April 2025 (UTC)

You can also show directly SVG view on CodePen on https://codepen.io/schlebe/full/gbbOrYK Schlebe (talk) 06:30, 17 April 2025 (UTC)

@Schlebe This also wouldn't work after thumbnailing. Right now there isn't a whole lot of interest in allowing interactive SVGs (Personally I think it would be cool, but it does open up a lot of things that need to be thought through.). If this is for Wikipedia, I was recently doing some experiments at w:User:Bawolff/Graph_demo which might be of an interest to you. Bawolff (talk) 09:59, 11 May 2025 (UTC)

Extra clear instructions for attribution

All too rarely are files from Commons attributed to their creator in accordance with their license. I've noted that instructions for attribution have been discussed multiple times before, and that "Use this file" provides an adequate text string for attribution.

For example, little Mr. Long-toes here gives us this:

Charles J Sharp, CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0>, via Wikimedia Commons

I think this text should be generated in an instantly visible place as well, for example:

Size of this preview: 800 × 533 pixels. [...]

Attribution: Charles J Sharp, CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0>, via Wikimedia Commons

Is this something that we, the community, would support?

Sinigh (talk) 11:54, 5 April 2025 (UTC)

 Support. RoyZuo (talk) 18:12, 5 April 2025 (UTC)

 Support. Jerimee (talk) 20:45, 5 April 2025 (UTC)

 Support per above and Commons:Village_pump#Copyleft_enforcement_-_concern_about_stretching_of_a_guideline etc. I think it is a good idea to make it more clear that reuse require better attribution. I think the template should provide a suggestion as default. --MGA73 (talk) 13:38, 7 April 2025 (UTC)

Support: per above. Also, CC licenses are being recognized by copyright authorities globally, such as in Russia where free licenses were recognized in 2014 (coinciding with liberalizing uses of architecture there). A few years before, according to Britannica, there was a ruling in 2008 by a Federal Appeals court in which free licenses "are enforceable under copyright law because they 'set conditions on the use of copyrighted work.' In the event that the conditions are violated, the license disappears, resulting in copyright infringement as opposed to the lesser violation of breach of contract." JWilz12345 (Talk|Contributions) 13:57, 7 April 2025 (UTC)

 Support It may not be enough, but at least it's a step in the right direction. --Cart (talk) 14:16, 7 April 2025 (UTC)

 Support --Adamant1 (talk) 15:09, 7 April 2025 (UTC)

 Support --Wilfredor (talk) 15:54, 7 April 2025 (UTC)

 Support I support this in principle but it only works if we entirely ban custom licenses and author templates they are not conform with Commons:Machine-readable data. On the exact wording: It also needs to include a link to the file page. GPSLeo (talk) 17:04, 7 April 2025 (UTC)

Has anyone done a formal review of what users put in custom license templates? If not, someone should. I suspect there are some common use cases - like requests to be attributed under a specific name, or contact information for commercial licensing - which can be addressed in a standard fashion, rather than having everyone do their own thing. Omphalographer (talk) 07:26, 8 April 2025 (UTC)

• Am I seeing right that the only difference is the word "attribution" in red? That is not remotely sufficient. "Failure to provide this attribution can incur legal penalties to the reuser, including heavy fines" needs to be added. Ikan Kekek (talk) 18:18, 7 April 2025 (UTC)
  • "Fines" seems the wrong term. "Fines" are paid to a government, not to the plaintiff in a civil suit. - Jmabel ! talk
  • The other (and more important) difference would be to place this prominently on the file page, rather than have it be something you have to click to see. - Jmabel ! talk 20:10, 7 April 2025 (UTC)

    "Fees" then. --Cart (talk) 20:16, 7 April 2025 (UTC)

    Fees or damages, yes. Money. Also,

    I totally agree with Jmabel on the importance of the warning being placed prominently on the file page. Ikan Kekek (talk) 23:22, 7 April 2025 (UTC)

    And to be fully clear, I  Support any notice that serves to make it more obvious to reusers what their responsibilities are and what consequences could befall them if they fail to credit their source properly. Ikan Kekek (talk) 21:26, 8 April 2025 (UTC)

    If you open a file in the Media Viewer there is already a generated attribution text as plain text and HTML but it is hidden behind a download button. In the implementation the text should definitely not be in red but aligned with the general style. GPSLeo (talk) 20:36, 7 April 2025 (UTC)

    Yeah, no red. I was just getting annoyed with several news outlets that only had "Wikimedia Commons" under CC BY photos, so I went a little crazy in my suggestion. Positively unhinged.

    As for the wording, don't y'all think we should go for something more concise and direct? For example, "If you use this file, you must attribute the author / you must include this information:" Doesn't have to be that, but you see what I mean.

    Whatever we decide on, we don't want informaton about attribution, fees etc. to appear when no attribution is needed. "Use this file" always provides a credit line, even when the file is PD. Sinigh (talk) 22:05, 7 April 2025 (UTC)

    And the good guys actually read this and do the right thing, even if they don't have to. (Right now I'm a bit in love with Shipping Australia.) This is what we are striving for. --Cart (talk) 22:38, 7 April 2025 (UTC)

 Support with Cart's fees.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 23:06, 7 April 2025 (UTC)

 Support -- Infrogmation of New Orleans (talk) 00:11, 8 April 2025 (UTC)

 Support. The Stockphoto gadget is a step in the right direction, but it's kind of clunky and easy to overlook - and doesn't show up at all on mobile devices! We can do better. Omphalographer (talk) 07:33, 8 April 2025 (UTC)

•  Support. A step in the right direction. I would be careful about including things like "Failure to provide this attribution can incur legal and/or financial penalties to the reuser". Licences and use-cases are complex, so it is not a good idea to provide legal advice.--Commander Keane (talk) 09:34, 8 April 2025 (UTC)

•  Oppose this seems to be a reaction to this complete communication disaster. I am not against correct attribution and will change to support this if we're not effectively scrapping the CL-TR-Guideline as a result: This approach here is going to add scary warning templates TO ALL FILES regardless of the problematic licenses. Images contributed under a CC4 license do not invite costly legal battles and should not be scary. And even most images contributed under CC1-CC3 license do not cause the respective uploaders to involve enforcement agencies... also no reason to scare people about fines & fees. My point is that: Images from those uploaders who do employ enforcement agencies to directly send large invoices to re-users, still require additional attention, and the easy-to-overlook warning label proposed above is of no help for those cases. --Enyavar (talk) 12:31, 8 April 2025 (UTC)

   Comment My suggestion was by no means a reaction to that or any other currently ongoing discussion. I have not participated in or even read it. I also advised against adding any legalese. My suggestion only attempts to address a frequent issue (unattributed works that require attribution when used), by adding clear instructions immediately below files, since they unfortunately seem to need it. Sinigh (talk) 13:44, 8 April 2025 (UTC)

   Comment The main problem, of course, is that not even professionals seem to have a clue on using free non-PD images. We need to make it obvious that you need to check what the licence requires from you. If we can tell the actual requirements in a good way that covers everything that isn't an obvious corner case, then good.

  The second problem, however, is that requirements can be complicated. I haven't figured out any watertight advice, other than to let a lawyer check the actual licence. Is the attribution line actually constructed so that it takes into account any place where requirements may be stated? How can we extract an attribution line from user templates? What if an attribution line is specified, but placed in the description field (by a non-author uploader)?

  –LPfi (talk) 12:09, 10 April 2025 (UTC)

  The proposal is just an attribution, I don't think there is a need to over think it. It may reduce copyright infringement cases, but it can never prevent them all and that is the best we can do. As you say, only a lawyer can interpret the licence and give thorough advice and it is up to reusers to find the correct attribution (and meet all of the other conditions). Of course, Commons can strive to extract the correct attribution - we should do that anyway. The attribution line makes it somewhat more obvious to reusers that the file has licence conditions, hopefully they will see the creativecommons.org link and actually make their way to the deed. Commander Keane (talk) 12:46, 10 April 2025 (UTC)

  Just thinking about it, it is essential to call it "Credit:" rather than "Attribution:" to avoid confusion with the term in the licence summary. Commander Keane (talk) 12:55, 10 April 2025 (UTC)

   Agree. I also agree that this shouldn't be made more complicated than it needs to be. The Stockphoto gadget always provides a credit line, with the addition of "Attribution not legally required" when applicable (which I didn't notice before). This new feature could work the same way. What works there should work here. Sinigh (talk) 13:45, 10 April 2025 (UTC)

 Comment I would support having the design team to redesign the file page to provide users with clear attribution instructions. The current UI is not user-friendly for those who just want to download a picture, leaving them confused about how to give attribution. Some people just attribute to "Wikimedia Commons" or "Wikipedia". --0x0a (talk) 10:31, 14 April 2025 (UTC)

• {s} Seems a sensible proposal, I'd prefer to see 'credit' used as the term. JayCubby (talk) 18:59, 12 May 2025 (UTC)
•  Support Incall ^talk 18:06, 19 May 2025 (UTC)