Template talk:Non-free use rationale 2
This is the talk page of a redirect that targets the page: • Template:Non-free use rationale Because this page is not frequently watched, present and future discussions, edit requests and requested moves should take place at: • Template talk:Non-free use rationale |
Logo
[edit]I really would like to see the options here to work like Template:logo fur, or to have a separate logo template that fills in all these fields. Logo information is pretty much always the same throughout Wikipedia, and we have consensus on the wording we currently use. As of this post, there's an example of what I mean at File:Eliassen Group Logo.png. — trlkly 13:39, 10 May 2012 (UTC)
Suggestion
[edit]I would like to suggest adding a link to WP:NFCC#4, which states that non-free content must be previously published or publicly displayed, in the "Source" category of the template. I think that putting the source of this content proves that it was publicly available before, demonstrating that the media fulfills this criteria. --qwekiop147 --> user, talk 02:18, 16 October 2012 (UTC)
Edit request on 17 November 2012
[edit]This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Files uploaded by the upload wizard often place a date field in this template. To make this field visible, please insert the following string after the publication #if statement, and before the WP:NFCC#7 line.
{{#if:{{{Date|{{{date|}}}}}}| !style="background: #ccf; text-align: right; padding-right: 0.4em; width: 15em"{{!}} Date {{!}} {{{Date|{{{date|}}}}}} {{!}}- }}
Thanks, 117Avenue (talk) 23:04, 17 November 2012 (UTC)
- Done, thanks for pointing this out. Don't know why I previously forgot to implement this. Fut.Perf. ☼ 01:25, 18 November 2012 (UTC)
Tracking
[edit]This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Please add {{Non-free media}} to this for tracking purposes. Werieth (talk) 20:26, 17 December 2012 (UTC)
- Done, thanks for the hint. Fut.Perf. ☼ 20:33, 17 December 2012 (UTC)
Edit request on 30 July 2013
[edit]This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
WP:NFCC#4 should be added per another user's comment above. Since there were no objections for almost one year, such an edit is unlikely to be controversial. Dogmaticeclectic (talk) 12:21, 30 July 2013 (UTC)
- OK, Done, see here. --Redrose64 (talk) 15:04, 30 July 2013 (UTC)
Edit request on 30 July 2013
[edit]This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
If the "Use in article" parameter is left blank, the brackets should not appear. (Note that this applies whether this is done intentionally, as it is at this template's documentation, or accidentally, say at an actual file description page, so using "includeonly" - or "noinclude" - would not suffice.)
Instead, some sort of message indicating that the parameter is required, as is done for the "Source" parameter, should appear. Dogmaticeclectic (talk) 17:29, 30 July 2013 (UTC)
- Done. An error message now appears, and the page is categorised in Category:Wikipedia non-free files lacking article backlink. — Mr. Stradivarius ♪ talk ♪ 05:41, 1 August 2013 (UTC)
NFCC#1 is not optional
[edit]NFCC#1 is policy requiring that two questions are asked in making the assessment of "No free equivalent"; neither question is optional. Of course, to reduce effort, common cases and common answers can be listed or referenced in the template documentation, but the answers to both questions should be recorded. Aquegg (talk) 11:33, 5 November 2013 (UTC)
- I appreciate your concerns about NFCC#1 observance, and I'm very much with you when it comes to the necessity of insisting on that aspect of it. However, please keep in mind that this template is primarily designed to record the answers elicited in the automated questionnaires of the upload script. The main design goal of those questionnaires is to get the uploader focussed on those aspects of a FUR that are non-predictable and require individual, non-trivial explanation, and not to bother them with redundant and predictable boilerplate items. There are many high-frequency use cases (all "identifying" items such as logos and cover art; portrait photographs; visual artworks that are the direct topic of an article, etc.) where replaceability with text is never an issue, and so it is entirely by design that the script will neither prompt the uploader for an explanation here nor automatically insert some boilerplate text about it. In this sense, the template field is factually optional – you can't change this fact by simply changing the documentation; you'd have to change the template itself and the FUW script. But doing so would be harmful, because every bit of redundant boilerplate text we insert in FURs, or encourage uploaders to add to FURs, will again strengthen the bad old prejudice that FURs are just a matter of bureaucratic red tape and formality for formality's sake as a whole. For the same reason, I'd be strongly opposed to including lists of "common cases and common answers" in any documentation, because that too would again encourage people to just start copying boilerplate text around, which is absolutely the last thing we ought to make them do. Fut.Perf. ☼ 12:24, 5 November 2013 (UTC)
- I think the key word here is traceability. Anyone should be able to read any FUR and check it against NFCC—it shouldn't matter whether the FUR was filled in manually, automatically, or somewhere in between. Bear in mind that a published FUR is viewable (and modifiable) in isolation from an upload script. If the only thought that goes into a FUR is "this use-case seems equivalent to that use-case", and the latter is identified as acceptable in an established guideline, then that's fine, as long it's recorded thus. So for example, "Could the subject ... ?", "No, per WP:SOME_GUIDELINE", is fine (again, it doesn't matter whether the answer was provided manually or automatically, based on other questions or perhaps context). Then, as long as WP:SOME_GUIDELINE is the result of discussion of WP:NFCC (most likely recorded in an RFC), we have the traceability required. Aquegg (talk) 13:37, 5 November 2013 (UTC)
- Sorry, but I cannot begin to understand how any of what you say would be an argument in favour of forcing uploaders to include answers on points that are entirely trivial and self-evident just for the sake of ticking off the complete list of all criteria. In any case, I'll soon revert your change to the documentation again, for the simple reason that, as I said earlier, it is simply factually untrue at the present time. Right now, the parameter is optional, because the script will keep producing FURs without filling it, and the template is currently not programmed to display a warning when it's not filled. If you want to change that, I'd have to ask you to open a discussion at the main WP:FUW talkpage, not here. Fut.Perf. ☼ 13:52, 5 November 2013 (UTC)
- Neither can you understand it, nor was I suggesting it. I think you're coming at this from the wrong angle: the raison d'être of a FUR is to show that NFCC has been satisfied (not to reflect how NFCC has been abstracted by an upload script). The point is, that if a FUR does not address all the points in NFCC, then it's not a valid FUR. Remember, this doc page is documenting (a template for) a FUR—not a script—and that the template can be used independently of the script. I don't have (and haven't had) any comment on the script. Aquegg (talk) 15:36, 5 November 2013 (UTC)
- I disagree with the claim that "if a FUR does not address all the points in NFCC, then it's not a valid FUR". That's exactly the wrong approach to doing FURs. FURs need to be read and written with common sense – which is just the thing that users are in danger of losing sight of when they are confronted with too much bureaucratic red tape. The point of NFCC is that all its criteria must be objectively met, but there is absolutely no requirement in our policy demanding that a FUR must mechanically address each and every one of these criteria explicitly. Demanding that it should have to do so would not only be useless, but actively harmful for people's actual understanding of the policy. People must be taught to provide explicit FUR arguments on just those points where it matters. Those points about an NFCC case that are obvious and self-evident not only can but should be left without explicit comment. Fut.Perf. ☼ 15:50, 5 November 2013 (UTC)
- Confusion still abounds, I'm afraid: first you say "The point of NFCC is that all its criteria must be objectively met", but then "Those points about an NFCC case that are obvious and self-evident ... should be left without explicit comment" (re-emphasised)—aren't obviousness and self-evidence subjective qualities? Aquegg (talk) 16:26, 5 November 2013 (UTC)
- Sorry, but that makes no sense at all. Fut.Perf. ☼ 17:12, 5 November 2013 (UTC)
- They're your words! Paraphrasing: "all NFCC criteria must be objectively met" is apparently contradicted by "NFCC criteria should be be omitted subjectively (i.e. if they seem obvious or self-evident)". However, rather than try to explain that, it would be much quicker if you could just to point to the guideline that describes whatever it is you're trying to say. Otherwise, one can only take WP:NFCC and WP:FUR at their word (i.e.: stating "why the subject can't be adequately conveyed by properly sourced text or using free content media" is a "necessary component"). Remember, just because something is a necessary component, doesn't mean that a helper script can't help to fill it in (given suitable prompts). A complete rationale is particularly important as NFCC is a "Wikipedia policy with legal considerations" — what seems obvious to you may not be obvious to a lawyer. Aquegg (talk) 18:28, 5 November 2013 (UTC)
- Sorry, but that makes no sense at all. Fut.Perf. ☼ 17:12, 5 November 2013 (UTC)
- Confusion still abounds, I'm afraid: first you say "The point of NFCC is that all its criteria must be objectively met", but then "Those points about an NFCC case that are obvious and self-evident ... should be left without explicit comment" (re-emphasised)—aren't obviousness and self-evidence subjective qualities? Aquegg (talk) 16:26, 5 November 2013 (UTC)
- I disagree with the claim that "if a FUR does not address all the points in NFCC, then it's not a valid FUR". That's exactly the wrong approach to doing FURs. FURs need to be read and written with common sense – which is just the thing that users are in danger of losing sight of when they are confronted with too much bureaucratic red tape. The point of NFCC is that all its criteria must be objectively met, but there is absolutely no requirement in our policy demanding that a FUR must mechanically address each and every one of these criteria explicitly. Demanding that it should have to do so would not only be useless, but actively harmful for people's actual understanding of the policy. People must be taught to provide explicit FUR arguments on just those points where it matters. Those points about an NFCC case that are obvious and self-evident not only can but should be left without explicit comment. Fut.Perf. ☼ 15:50, 5 November 2013 (UTC)
- Neither can you understand it, nor was I suggesting it. I think you're coming at this from the wrong angle: the raison d'être of a FUR is to show that NFCC has been satisfied (not to reflect how NFCC has been abstracted by an upload script). The point is, that if a FUR does not address all the points in NFCC, then it's not a valid FUR. Remember, this doc page is documenting (a template for) a FUR—not a script—and that the template can be used independently of the script. I don't have (and haven't had) any comment on the script. Aquegg (talk) 15:36, 5 November 2013 (UTC)
Template-protected edit request on 13 September 2019
[edit]This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
The </td>
appears to be stripped, although it affects only a small number of files. There's no need for it because the template is otherwise implemented using Wiki table markup with pipes and hyphens rather than raw HTML markup. So, get rid of it. — Anomalocaris (talk) 05:15, 13 September 2019 (UTC)
- Done — JJMC89 (T·C) 05:20, 13 September 2019 (UTC)
- JJMC89: Thanks! —Anomalocaris (talk) 06:27, 20 November 2019 (UTC)
NFCCP#4 "Immediate" Source clarification
[edit]Would it make sense to clarify immediate source in the documentation? At least one user has found this confusing, thinking that it means a link to the image (the host url) and not to the site/page where the image is displayed/published/used, per WP:NFCCP#4. ★ Bigr Tex 19:50, 17 April 2020 (UTC)
Multiple uses on same file
[edit]When a file is used on more than one paged, this template is used multiple times, with the only difference being the |Article=
parameter value. Is there a reason why we can't add |Article#=
parameters (|Article2=
, |Article3=
)? --Gonnym (talk) 08:23, 9 November 2020 (UTC)
Template-protected edit request on 16 May 2021
[edit]This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Please update from the sandbox, this fixes an issue where "Source (WP:NFCC#4)" is displayed in the bottom left corner of the media viewer and sets the custom attribution to this. It's also not supposed to be used in this way either, as its intended use is to generate custom attribution specified by the author of a freely licensed work. Removing this means that the media viewer correctly generates attribution using the "fileinfotpl_aut" and "fileinfotpl_src" IDs. Dylsss(talk contribs) 23:47, 16 May 2021 (UTC)
source cite web limitations
[edit]@Pppery, Jonesey95, JJMC89, FlightTime, Andy M. Wang, Tgr (WMF), and Samsara: The |source=
parameter will accept {{cite}}
templates, but |script-title=
generates two stripped tags, one for bdi and one for cite. See File:Korean Woman.jpg, and if it's edited, see the version of 15:45, 31 December 2021. Please fix. —Anomalocaris (talk) 07:00, 1 January 2022 (UTC)
- Someone used {{!}} inside a table cell, which can cause problems, I think. Another editor has replaced it with a colon. I think replacing it with
|
would also work. – Jonesey95 (talk) 16:46, 1 January 2022 (UTC)
because because because
[edit]Can the word "because" be stripped from "Not replaceable with free media because" and "Not replaceable with textual coverage because"? It doesn't look professional (to me) as it's not part of a sentence, it's a table cell. It's filler. We don't need filler. — Alexis Jazz (talk or ping me) 15:00, 15 May 2022 (UTC)
Should we test the Date= parameter value to see if the image could be moved to Commons?
[edit]I have been working with BD2412 to set up subcategories of Category:Non-free biographical images, in part to look for images that are currently tagged as non-free that might have entered the public domain. While doing that work, and finding pages like File:KatzBreweryPaterson.jpeg, published in 1920, it occurred to me that there may be images tagged with this template that have entered the public domain. Given that this template has a |Date=
parameter, we should be able to test that parameter to see if the image may have entered the public domain, categorize those pages, and then go through them to move them to Commons or whatever the right process is.
I understand less than all of you about copyright terms and the public domain, but I know that it can get complicated in a hurry, so this test may not be useful. If the above seems worth doing, I'm willing to do the template coding if this seems like a useful project. – Jonesey95 (talk) 04:34, 29 September 2023 (UTC)
- It is certainly worth generating a list of possible targets to check further. BD2412 T 04:42, 29 September 2023 (UTC)