Jump to content

Wikipedia talk:Image use policy: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
Changes: <sigh>
Line 184: Line 184:
:Related to that discussion, it's been brought up there that our image use policy contains material that is less policy (images must be properly licensed) and more stylistic guidance (images should generally carry a caption), and that this material has a large amount of overlap with [[MOS:IMAGE]]. My impression is that the whole "Adding images to articles" section of this policy (with the possible exception of the callout to NOTCENSORED) is actually a mixture of howto (redundant with [[Wikipedia:Image markup]]) and guidance (redundant with [[MOS:IMAGE]]). Maybe we can have a discussion here about simplifying and un-[[WP:CREEP]]ing this section to keep only the pieces that really should be policy, and if so identifying which pieces those are? If possible I think we should keep such a discussion limited to debating whether something in this part of the policy really should be policy or guideline, rather than whether its meaning should be changed, since otherwise we'll end up with as big a mess as we already have over on the MOS talk page. —[[User:David Eppstein|David Eppstein]] ([[User talk:David Eppstein|talk]]) 01:24, 29 January 2016 (UTC)
:Related to that discussion, it's been brought up there that our image use policy contains material that is less policy (images must be properly licensed) and more stylistic guidance (images should generally carry a caption), and that this material has a large amount of overlap with [[MOS:IMAGE]]. My impression is that the whole "Adding images to articles" section of this policy (with the possible exception of the callout to NOTCENSORED) is actually a mixture of howto (redundant with [[Wikipedia:Image markup]]) and guidance (redundant with [[MOS:IMAGE]]). Maybe we can have a discussion here about simplifying and un-[[WP:CREEP]]ing this section to keep only the pieces that really should be policy, and if so identifying which pieces those are? If possible I think we should keep such a discussion limited to debating whether something in this part of the policy really should be policy or guideline, rather than whether its meaning should be changed, since otherwise we'll end up with as big a mess as we already have over on the MOS talk page. —[[User:David Eppstein|David Eppstein]] ([[User talk:David Eppstein|talk]]) 01:24, 29 January 2016 (UTC)


== Changes ==
==Changes==

{{u|EEng}} and {{u|Adam Cuerden}}, could you gain consensus for changes to the policy? It becomes hard to work out what the real changes are and what is just copy-editing, especially given the confusion at the guideline.
{{u|EEng}} and {{u|Adam Cuerden}}, could you gain consensus for changes to the policy? It becomes hard to work out what the real changes are and what is just copy-editing, especially given the confusion at the guideline.


Line 205: Line 204:
::::But none of that really matters, because useful or not these are substantive changes which, being sensibly objected to, should be discussed first. And as both I and David Eppstein have said repeatedly (e.g. [https://wiki.riteme.site/?diff=702211531]), this is guideline or how-to material doesn't belong here on a policy page, but rather over at MOS/Images, if it belongs anywhere. And as also already stated [https://wiki.riteme.site/?diff=702177609&oldid=702177358], this entire ''section'' of the policy should be merged over to MOS/Images and removed from here, not further bloated here.
::::But none of that really matters, because useful or not these are substantive changes which, being sensibly objected to, should be discussed first. And as both I and David Eppstein have said repeatedly (e.g. [https://wiki.riteme.site/?diff=702211531]), this is guideline or how-to material doesn't belong here on a policy page, but rather over at MOS/Images, if it belongs anywhere. And as also already stated [https://wiki.riteme.site/?diff=702177609&oldid=702177358], this entire ''section'' of the policy should be merged over to MOS/Images and removed from here, not further bloated here.
:::::'''[[User:EEng#s|<font color="red">E</font>]][[User talk:EEng#s|<font color="blue">Eng</font>]]''' 05:03, 29 January 2016 (UTC)
:::::'''[[User:EEng#s|<font color="red">E</font>]][[User talk:EEng#s|<font color="blue">Eng</font>]]''' 05:03, 29 January 2016 (UTC)

{''serial edit conflicts'')Folks that find it "{{xt|hard to work out what the real changes are and what is just copy-editing}}" might wish to consider a self denying ordinance with regard to editing the accompanying policy page (or study the material they contemplate reverting long and hard) before they make [https://wiki.riteme.site/w/index.php?title=Wikipedia:Image_use_policy&diff=next&oldid=702177609 this kind of edit].

Mind you, I wholeheartedly agree with the implication of the accompanying edit summary for that howler: "{{xt|back to Adam, please gain consensus for these changes (this is a policy page)}}" and not some strange new game of 'policy ping-pong'.

May I entreat ''anyone'' that wishes to change policy (or even the emphasis, or is tempted to sprinkle a few little new and ever-so-helpful 'how-to' notes) rather than mere [[Wikipedia:Basic copyediting|copyediting]] and removing howlers, to discuss the changes they think are needed on this discussion page first?

Besides the obvious benefit that signalling the change here first will ensure that the 'improvement' has consensus, prior community input may well catch factual errors such as [https://wiki.riteme.site/w/index.php?title=Wikipedia:Image_use_policy&diff=prev&oldid=702058534 this edit which introduced the factually incorrect statement that "inline images, which ''cannot'' use <code>upright=</code> are an obvious exception"], '''before''' installation on the live page. (Inline images, if the <code>frameless</code> syntax is used '''can''' display images inline. Admittedly, there is a drawback that the range of displayed sizes is limited to increments of 10px, but that won't be a handicap for many inline icons which would often otherwise use a fixed size of 20px, since this is equivalent to <code>frameless|upright=0.1</code> for most of our readers who have not logged on or for those registered users who have not changed their base thumbnail preference size from 220px.) [[User:BushelCandle|BushelCandle]] ([[User talk:BushelCandle|talk]]) 05:10, 29 January 2016 (UTC)

Revision as of 05:10, 29 January 2016

Annotated image policy

Notified: WP:IM, WP:ILL, WP:PIC, MOS:IMAGE, TMP:AI4, WP:MCB, WP:GEN, WP:BIOL

Currently the only advice on image annotation seems to be Picture tutorial (WP:PIC) and a sentence in the manual of style (MOS:IMAGE). I am keen to more frequently use wikilinked image annotation (TMP:AI4) but thought it would be good to have some consensus on when/where it is appropriate/inappropriate. For example, the DNA article contains:

Which if any could appropriately have interactive wikilinked annotations? What are the general principles for when it is appropriate? When is it inappropriate? T.Shafee(Evo﹠Evo)talk 02:13, 19 April 2015 (UTC)[reply]

I do not see any fundamental difference between placing text and associated wikilinks in an image vs. the image caption. Including wikilinks directly in the image is often clearer. The only disadvantage I see is that it may make it somewhat more complicated to port the image to other languages. I also do not see any fundamental difference between including Wikilinks in the main text vs. images. The same link guidelines apply to both. In particular, one should guard against overlinking. Boghog (talk) 06:11, 19 April 2015 (UTC)[reply]
I've really liked the ones I've seen you create. (And shouldn't it be easier to port to other languages than an image with its own text would be?) I'm just not sure I see why there's a need for a policy on the topic. Did someone object to one of them? Opabinia regalis (talk) 07:09, 19 April 2015 (UTC)[reply]
Currently the wikilinked annotation template is only available in English and Welsh. To port the annotated image to another language, one also needs to port the template (and ideally also the template documentation). Furthermore maintenance of these templates in other languages is a headache. So as it currently stands, it is easier to port a text free graphic and associated caption vs. an wikilinked annotated image. Boghog (talk) 09:00, 19 April 2015 (UTC)[reply]
I've not yet had anyone object to the interactive images I've made so far. I mainly want to pre-empt any future problems. Agree that there's no sense in overlinking an image where the labels are not a key feature. I think a lot of summary images could do with wikilinked labels though. Good point that the templates don't necessarily work in other languages - I hadn't thought of that. I'll make sure that the non-interactive images are always available. T.Shafee(Evo﹠Evo)talk 08:07, 21 April 2015 (UTC)[reply]

Per Wikipedia:Manual_of_Style/Images (specifically, the section titled "Making images yourself"), annotating text onto images is the preferred method for including text in images. Seppi333 (Insert ) 16:39, 22 April 2015 (UTC)[reply]
Added: Personally, I think it's only worthwhile to use image annotation when there's image text that would be benefit from having a link to the associated article(s) in the image. In some cases, it may be useful to use both regular image text (for text which is less relevant to the purpose of the image) and annotated text (for article links/etc) in an image. Seppi333 (Insert ) 11:59, 25 April 2015 (UTC)[reply]

Cropped vs. full images

Map of Lorem ipsum. Clicking on the image itself takes you to an uncropped version of the full map, while clicking on the little rectangle thingee here in the caption area takes you to the formal description page for the cropped img

I hope you'll excuse my injecting a somewhat related issue. If a large image will not display well at thumbnail size (or there's a small part of it that's most important for the purposes of the article) for some time I've been using link= to allow a crop of that image to be displayed in the thumbnail, but if the user clicks on the image he's taken to the original, full (uncropped) image. This way the reader gets the best of both worlds.

Unfortunately, I've gotten static on this from that kind of editor who's hostile to anything they haven't see before -- see [1] (open the collapse box, and you can stop reading at the end of the third image). Does anyone see anything wrong with this technique? And if not, can we add something explicitly here, with an example? EEng (talk) 14:59, 21 April 2015 (UTC)[reply]

This sounds to be a good option. I would use it if I knew how. I do not think it needs to be used in all cases of cropping, but sometimes it will make for a better thumbnail, eg a zoom in of a face for a portrait, or a building in its context. It would also be good for WP:DYK, where the thumbnail is even smaller. Graeme Bartlett (talk) 22:55, 21 April 2015 (UTC)[reply]
Your examples are exactly right. It's very easy -- here's the markup:
[[File:CavendishVermont 1869Map Beers AnnotatedPhineasGageLocations cropped.jpg
|link=File:CavendishVermont_1869Map_Beers_AnnotatedPhineasGageLocations.jpg
|thumb|upright=1.2
|Map of Lorem ipsum. Clicking on the image itself takes you to an uncropped version of the full map, while clicking on the little rectangle thingee here in the caption area takes you to the formal description page for the cropped img
]]
I'd really like to know whether people think this page should explicitly acknowledge this usage, so I don't have to argue with knowitalls about it in the future. EEng (talk) 23:35, 21 April 2015 (UTC)[reply]

Just as long as there is a link to the image file page somewhere in the caption, on the image, or as the image background link, it will suffice, since this satisfies the requirement to indicate the image copyright/licensing info (i.e., attribution requirements). There is no policy or legal requirement to have an image background link to a copyright page. This info could even be listed in the article itself, although that would be a bit tacky for an encylcopedia IMO. I should probably note that attribution is typically provided on the same page as the image in most external sources (e.g., academic journals, textbooks, webpages, etc)... linking to another page for attribution as we do is actually somewhat atypical.

As an example of an alternative way to provide attribution, I recently coded a parameter to add an info icon (i.e., this thing: ) to the end of a caption to link to the associated commons page when a background link is not used (note that template:annotated image 4 requires that an image have a commons page). If using an image-insertion template, it is a good idea to indicate/link to the image commons page somewhere on that page or its documentation as well, as was done with the example below.

Template:Psychostimulant addiction – example template without a background link
Signaling cascade in the nucleus accumbens that results in psychostimulant addiction
The image above contains clickable links
This diagram depicts the signaling events in the brain's reward center that are induced by chronic high-dose exposure to psychostimulants that increase the concentration of synaptic dopamine, like amphetamine, methamphetamine, and phenethylamine. Following presynaptic dopamine and glutamate co-release by such psychostimulants,[1][2] postsynaptic receptors for these neurotransmitters trigger internal signaling events through a cAMP-dependent pathway and a calcium-dependent pathway that ultimately result in increased CREB phosphorylation.[1][3][4] Phosphorylated CREB increases levels of ΔFosB, which in turn represses the c-Fos gene with the help of corepressors;[1][5][6] c-Fos repression acts as a molecular switch that enables the accumulation of ΔFosB in the neuron.[7] A highly stable (phosphorylated) form of ΔFosB, one that persists in neurons for 1–2 months, slowly accumulates following repeated high-dose exposure to stimulants through this process.[5][6] ΔFosB functions as "one of the master control proteins" that produces addiction-related structural changes in the brain, and upon sufficient accumulation, with the help of its downstream targets (e.g., nuclear factor kappa B), it induces an addictive state.[5][6]

References

  1. ^ a b c Renthal W, Nestler EJ (September 2009). "Chromatin regulation in drug addiction and depression". Dialogues in Clinical Neuroscience. 11 (3): 257–268. doi:10.31887/DCNS.2009.11.3/wrenthal. PMC 2834246. PMID 19877494. [Psychostimulants] increase cAMP levels in striatum, which activates protein kinase A (PKA) and leads to phosphorylation of its targets. This includes the cAMP response element binding protein (CREB), the phosphorylation of which induces its association with the histone acetyltransferase, CREB binding protein (CBP) to acetylate histones and facilitate gene activation. This is known to occur on many genes including fosB and c-fos in response to psychostimulant exposure. ΔFosB is also upregulated by chronic psychostimulant treatments, and is known to activate certain genes (eg, cdk5) and repress others (eg, c-fos) where it recruits HDAC1 as a corepressor. ... Chronic exposure to psychostimulants increases glutamatergic [signaling] from the prefrontal cortex to the NAc. Glutamatergic signaling elevates Ca2+ levels in NAc postsynaptic elements where it activates CaMK (calcium/calmodulin protein kinases) signaling, which, in addition to phosphorylating CREB, also phosphorylates HDAC5.
    Figure 2: Psychostimulant-induced signaling events
  2. ^ Broussard JI (January 2012). "Co-transmission of dopamine and glutamate". The Journal of General Physiology. 139 (1): 93–96. doi:10.1085/jgp.201110659. PMC 3250102. PMID 22200950. Coincident and convergent input often induces plasticity on a postsynaptic neuron. The NAc integrates processed information about the environment from basolateral amygdala, hippocampus, and prefrontal cortex (PFC), as well as projections from midbrain dopamine neurons. Previous studies have demonstrated how dopamine modulates this integrative process. For example, high frequency stimulation potentiates hippocampal inputs to the NAc while simultaneously depressing PFC synapses (Goto and Grace, 2005). The converse was also shown to be true; stimulation at PFC potentiates PFC–NAc synapses but depresses hippocampal–NAc synapses. In light of the new functional evidence of midbrain dopamine/glutamate co-transmission (references above), new experiments of NAc function will have to test whether midbrain glutamatergic inputs bias or filter either limbic or cortical inputs to guide goal-directed behavior.
  3. ^ Kanehisa Laboratories (10 October 2014). "Amphetamine – Homo sapiens (human)". KEGG Pathway. Retrieved 31 October 2014. Most addictive drugs increase extracellular concentrations of dopamine (DA) in nucleus accumbens (NAc) and medial prefrontal cortex (mPFC), projection areas of mesocorticolimbic DA neurons and key components of the "brain reward circuit". Amphetamine achieves this elevation in extracellular levels of DA by promoting efflux from synaptic terminals. ... Chronic exposure to amphetamine induces a unique transcription factor delta FosB, which plays an essential role in long-term adaptive changes in the brain.
  4. ^ Cadet JL, Brannock C, Jayanthi S, Krasnova IN (2015). "Transcriptional and epigenetic substrates of methamphetamine addiction and withdrawal: evidence from a long-access self-administration model in the rat". Molecular Neurobiology. 51 (2): 696–717 (Figure 1). doi:10.1007/s12035-014-8776-8. PMC 4359351. PMID 24939695.
  5. ^ a b c Robison AJ, Nestler EJ (November 2011). "Transcriptional and epigenetic mechanisms of addiction". Nature Reviews Neuroscience. 12 (11): 623–637. doi:10.1038/nrn3111. PMC 3272277. PMID 21989194. ΔFosB serves as one of the master control proteins governing this structural plasticity. ... ΔFosB also represses G9a expression, leading to reduced repressive histone methylation at the cdk5 gene. The net result is gene activation and increased CDK5 expression. ... In contrast, ΔFosB binds to the c-fos gene and recruits several co-repressors, including HDAC1 (histone deacetylase 1) and SIRT 1 (sirtuin 1). ... The net result is c-fos gene repression.
    Figure 4: Epigenetic basis of drug regulation of gene expression
  6. ^ a b c Nestler EJ (December 2012). "Transcriptional mechanisms of drug addiction". Clinical Psychopharmacology and Neuroscience. 10 (3): 136–143. doi:10.9758/cpn.2012.10.3.136. PMC 3569166. PMID 23430970. The 35-37 kD ΔFosB isoforms accumulate with chronic drug exposure due to their extraordinarily long half-lives. ... As a result of its stability, the ΔFosB protein persists in neurons for at least several weeks after cessation of drug exposure. ... ΔFosB overexpression in nucleus accumbens induces NFκB ... In contrast, the ability of ΔFosB to repress the c-Fos gene occurs in concert with the recruitment of a histone deacetylase and presumably several other repressive proteins such as a repressive histone methyltransferase
  7. ^ Nestler EJ (October 2008). "Transcriptional mechanisms of addiction: Role of ΔFosB". Philosophical Transactions of the Royal Society B: Biological Sciences. 363 (1507): 3245–3255. doi:10.1098/rstb.2008.0067. PMC 2607320. PMID 18640924. Recent evidence has shown that ΔFosB also represses the c-fos gene that helps create the molecular switch—from the induction of several short-lived Fos family proteins after acute drug exposure to the predominant accumulation of ΔFosB after chronic drug exposure
  1. ^
      (Text color) Transcription factors

Seppi333 (Insert ) 16:33, 22 April 2015 (UTC)[reply]

  • Wow, you certainly, um, know how to put an image together! We are obviously in violent agreement, but if you read the (beginning of) the discussion I linked, you'll see there are editors who simply cannot see beyond reasoning of the form "You must do X because I've only seen X, and that's the reason you must do X. QED." So, how might we acknowledge this technique on this page? I think it's one which could be used to excellent effect in a lot of articles, and it's very simple once someone points out the syntax. EEng (talk) 18:26, 22 April 2015 (UTC)[reply]
Coverage of attribution requirements involving the link parameter, or no background link, is basically summarized at Wikipedia:Extended image syntax partly in the lead and mostly in Wikipedia:Extended image syntax#Link. The mere fact that the unlinked syntax is covered and the attribution requirements are explained there is an implicit endorsement of retargeting or removing background links altogether. I'd suggest just pointing people to that page for now, although the syntax page text involving links/attribution for non-PD images could just as well be added to this page. Seppi333 (Insert ) 11:37, 25 April 2015 (UTC)[reply]

I don't really understand what you've said -- what does "there is an implicit endorsement of retargeting or removing background links altogether" mean? In 2009 someone added this [2] without any discussion that I can see:

Note that link cannot be used in conjunction with thumb as thumb is always meant to link to the larger version of the image.

I think what this was getting at is that when the reader clicks the image he shouldn't get an easter egg -- something unexpected; he expects to get "more" of the little image in the thumb. The most obvious sense of "more" is the same image, just bigger; but it seems to me completely reasonable to extend that to the possibility of a full image, of which the thumb was a crop -- as someone mentioned above, the thumb might have been a close-up of a face, with the full image giving a larger context. How about this:

If link is used with thumb, the linked image should be a full, uncropped image from which the thumbnail was cropped, or a full document from which thumbnail was a single page, or crop of a single page.

EEng (talk) 14:16, 25 April 2015 (UTC)[reply]

I was referring to the following lead text on that WP:EIS:

Link
Link the image to a different resource, or to nothing. Must not be set for non-public domain images unless attribution is provided in some other fashion.
— Wikipedia:Extended image syntax lead

It explicitly states that link removal should not be done unless another form of attribution is used. Since the page doesn't state that the background link shouldn't be removed in any circumstance and given that the page explains how to remove the background link in WP:EIS#Link, the page is implicitly supporting the removal of the background link as a display option, assuming attribution is provided by another means. If removing the background link wasn't an acceptable option in articles at all, the page would've stated that instead of mention the attribution condition in the above quote. Seppi333 (Insert ) 15:56, 25 April 2015 (UTC)[reply]
I see. You seem to be using the phrase link removal to mean setting link= to a nonempty value -- that's kind of confusing (or am I misunderstanding?). But there's still the problem that the text I quoted in my earlier post does say that, in the specific context of a thumbnail, link= shouldn't be used at all. Would you agree that text is inappropriate and should be modified along the lines of my suggestion above? EEng (talk) 16:33, 25 April 2015 (UTC)[reply]
Your interpretation of my meaning is correct.
As for thumbs, as long as attribution to the associated image(s) (i.e., cropped version, full version, etc) is provided via an alternate method OR on the target page of the link, it should be perfectly fine to link a thumb. {{Annotated image 4}} actually retargets the link to the file's wikimedia commons page for all images (note that this template produces a thumbnail frame/caption which looks virtually identical to normal thumbs) which are displayed using this template.
With regard to cropped/full images, it would probably be faster and simpler to use a template to crop an image instead of upload a cropped file; when cropping with a template, the default image link would be the full version of the image since no cropped image file is used. Both {{annotated image}} and {{annotated image 4}} (and I imagine several other image templates as well) are able to crop and/or expand the area around an image. Seppi333 (Insert ) 01:31, 26 April 2015 (UTC)[reply]
Template cropping: these 3 images use the same image file
Example 1
cropped horizontally; expanded vertically
Racemic amphetamine
The image above contains clickable links
Full version, expanded vertically (the area where the wikilinks appear is not part of the image)
Example 2
cropped horizontally; expanded vertically

You'll understand my saying that I really don't want to navigate all that syntax for every image -- I'd just like to use link=, so can we agree that the changed text I proposed above is OK? EEng (talk) 01:45, 26 April 2015 (UTC)[reply]

If link is used with thumb, the linked image should be a full, uncropped image from which the thumbnail was cropped, or a full document from which thumbnail was a single page, or crop of a single page.
Add the word "generally" between "linked image should" and "be a full" and I think that's fine. It's best not to mandate a particular method for layout/syntax when there may be unusual cases in which it would be better if done differently.
In any event, should you ever decide to use it, the parameters in the AI4 template mirror the syntax in a double-bracketed image/file call, and the remainder are pretty straightforward to use. Seppi333 (Insert ) 05:28, 29 April 2015 (UTC)[reply]

Reviving discussion

Any objection to the text Seppi333 discusses above, with (as he/she suggests) generally inserted, as follows –

If link is used with thumb, the linked image should generally be a full, uncropped image from which the thumbnail was cropped, or a full document from which thumbnail was a single page, or crop of a single page.

 – ? EEng (talk) 01:16, 23 August 2015 (UTC)[reply]

<bump> EEng (talk) 15:15, 10 January 2016 (UTC)[reply]

Band timeline images

A discussion is happening at Wikipedia talk:WikiProject Musicians#Create Member Section/Timeline Standards related to standards around generated timelines. The suggestions seem to violate the WP:IMGSIZE. It would probably be best if interested parties could comment to either support the 800 pixel width suggestions or give reasons against them. Walter Görlitz (talk) 05:43, 10 November 2015 (UTC)[reply]

Opinions are needed on the following matter: Wikipedia talk:Manual of Style/Images#"Articles about ethnic groups or similarly large human populations should not be illustrated by a gallery of images of group members". A WP:Permalink for it is here. Flyer22 Reborn (talk) 23:53, 8 January 2016 (UTC)[reply]

Deleting images

Item 5 of WP:IUP#Deleting images currently reads "For disputed non-free files, you may alternatively use a listing on the non-free content review page.", but "NFCR" was merged into WP:FFD ("Files for Discussion") a few months back and now all non-free content matters are being discussed there. There are still some open threads on NFCR, but these are slowly being closed and archived or moved to FFD. Could someone update the sentence and add a wikilink to FFD? I don't mind doing, but since this is a policy page I felt it's best to ask here first. -- Marchjuly (talk) 14:29, 10 January 2016 (UTC)[reply]

Semiprotect, please

Can some kind admin permanently semiprotect this page, plz? Of scores of IP edits over the last few years, maybe two weren't vandalism. EEng (talk) 01:56, 13 January 2016 (UTC)[reply]

Opinions requested

Please see discussion at Talk:Harley-Davidson XR-750#Gallery usage. --Dennis Bratland (talk) 18:12, 21 January 2016 (UTC)[reply]

Image size discussion at Wikipedia talk:Manual of Style/Images

Opinions are needed on the following matter: Wikipedia talk:Manual of Style/Images#Fixing images below the default size. A WP:Permalink for it is here. The discussion concerns whether or not we should keep the following wording: "As a general rule, images should not be set to a larger fixed size than the 220px default (users can adjust this in their preferences). If an exception to the general rule is warranted, forcing an image size to be either larger or smaller than the 220px default is done by placing a parameter in the image coding." The latest aspect of the discussion is the 1.4 Amended proposal (2A) subsection. Flyer22 Reborn (talk) 07:13, 25 January 2016 (UTC)[reply]

This discussion has progressed to a WP:RfC: Wikipedia talk:Manual of Style/Images#RfC: Should the guideline maintain the "As a general rule" wording or something similar?. A WP:Permalink is here. Flyer22 Reborn (talk) 21:51, 25 January 2016 (UTC)[reply]

Related to that discussion, it's been brought up there that our image use policy contains material that is less policy (images must be properly licensed) and more stylistic guidance (images should generally carry a caption), and that this material has a large amount of overlap with MOS:IMAGE. My impression is that the whole "Adding images to articles" section of this policy (with the possible exception of the callout to NOTCENSORED) is actually a mixture of howto (redundant with Wikipedia:Image markup) and guidance (redundant with MOS:IMAGE). Maybe we can have a discussion here about simplifying and un-WP:CREEPing this section to keep only the pieces that really should be policy, and if so identifying which pieces those are? If possible I think we should keep such a discussion limited to debating whether something in this part of the policy really should be policy or guideline, rather than whether its meaning should be changed, since otherwise we'll end up with as big a mess as we already have over on the MOS talk page. —David Eppstein (talk) 01:24, 29 January 2016 (UTC)[reply]

Changes

EEng and Adam Cuerden, could you gain consensus for changes to the policy? It becomes hard to work out what the real changes are and what is just copy-editing, especially given the confusion at the guideline.

Image size is something editors regularly fall out about, because a few editors like to impose their image-size preferences (often by reducing size) on articles they're otherwise not involved in. This policy and the guideline act as ammunition, so changes that reduce choice will affect a lot of people. SarahSV (talk) 04:09, 29 January 2016 (UTC)[reply]

I was simply trying to provide what I would have thought was non-controversial, neutral information. I kind of get the impression EEng just is deleting for deletion's sake. He doesn't even seem to actually object to most of it, just doesn't like discussion. Adam Cuerden (talk) 04:16, 29 January 2016 (UTC)[reply]
Neutral information about what technical choices work best when formatting images belongs on Wikipedia:Image markup, not here. This page should only be about actual policies that must be followed when formatting images. —David Eppstein (talk) 04:19, 29 January 2016 (UTC)[reply]
(ec) I agree that it's very annoying when people object to copy-editing and helpful changes, and I'm sorry to do that. It just seems that someone (EEng?, I'm not sure) is trying to reduce choice even further, and I know that it will affect people, particularly those who work in art. SarahSV (talk) 04:23, 29 January 2016 (UTC)[reply]
[Edit conflicted a few times] :::His objections include "editors sophisticated enough to use these features will realize this" - so he removes it from the guideline, even though his summary implicitly agrees the statement is true. He objects to this because he can see no evidence it's a problem (because no-one is using upright for the purpose being warned about anywhere.) Again, we're writing for all users, including newbies. And with that removal, any warning about the otherwise undocumented rounding off to the nearest 10px that upright does is removed as well. It's naive to think that we should have a policy, and not engage with how it's applied. Both those aren't about technical decisions, they're simple clarifications of when using upright is impossible. No-one is seriously advocating for not using px where upright simply wouldn't work; stating a few examples of when it doesn't work will help clarify the policy. Adam Cuerden (talk) 04:28, 29 January 2016 (UTC)[reply]
And, you know, if one or two of the examples are genuinely controversial - sure. But are we seriously saying we should use Upright to randomly select based on user preferences between a 20px or 30px wide inline image, say, and, furthermore, not documenting that's a problem is terrible policy writing.
Adam Cuerden (talk) 04:33, 29 January 2016 (UTC)[reply]
Your first mistake is in your first sentence, where you use the word "guideline". This page is about a policy, not a guideline. It should only be for things where we say editors *must* do things, not that they *should* do them, or that in most cases those things are the best choice. —David Eppstein (talk) 04:37, 29 January 2016 (UTC)[reply]
Well, yes, but we say "You must use upright whereever possible" I think it's valid to say "It is not possible in these situations". Otherwise, it makes it sound like upright is always possible to use - and therefore, per policy, must be used (even though it won't work). Adam Cuerden (talk) 04:46, 29 January 2016 (UTC)[reply]
No, because it said "In most cases upright=scaling factor should be used...". In most cases... should is not must, and leaves plenty of room for exceptions. As for things you said in your earlier post:
  • I understand that scaling via upright rounds the width, but I don't see why that's some kind of danger editors need to be warned about
  • And yes, editors using CSS image crop and the gallery tags aren't newbies, and will know without being told that that's exactly the kind of situation where upright won't work [3]
  • And there's no purpose to statements like "Also, note that most articles on Wikipedia predate the existence of upright=, or at least before guidelines were updated to suggest using it, and will likely use px for now" [4]
But none of that really matters, because useful or not these are substantive changes which, being sensibly objected to, should be discussed first. And as both I and David Eppstein have said repeatedly (e.g. [5]), this is guideline or how-to material doesn't belong here on a policy page, but rather over at MOS/Images, if it belongs anywhere. And as also already stated [6], this entire section of the policy should be merged over to MOS/Images and removed from here, not further bloated here.
EEng 05:03, 29 January 2016 (UTC)[reply]

{serial edit conflicts)Folks that find it "hard to work out what the real changes are and what is just copy-editing" might wish to consider a self denying ordinance with regard to editing the accompanying policy page (or study the material they contemplate reverting long and hard) before they make this kind of edit.

Mind you, I wholeheartedly agree with the implication of the accompanying edit summary for that howler: "back to Adam, please gain consensus for these changes (this is a policy page)" and not some strange new game of 'policy ping-pong'.

May I entreat anyone that wishes to change policy (or even the emphasis, or is tempted to sprinkle a few little new and ever-so-helpful 'how-to' notes) rather than mere copyediting and removing howlers, to discuss the changes they think are needed on this discussion page first?

Besides the obvious benefit that signalling the change here first will ensure that the 'improvement' has consensus, prior community input may well catch factual errors such as this edit which introduced the factually incorrect statement that "inline images, which cannot use upright= are an obvious exception", before installation on the live page. (Inline images, if the frameless syntax is used can display images inline. Admittedly, there is a drawback that the range of displayed sizes is limited to increments of 10px, but that won't be a handicap for many inline icons which would often otherwise use a fixed size of 20px, since this is equivalent to frameless|upright=0.1 for most of our readers who have not logged on or for those registered users who have not changed their base thumbnail preference size from 220px.) BushelCandle (talk) 05:10, 29 January 2016 (UTC)[reply]