Jump to content

Help talk:Citation Style 1/Archive 32

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< Help talk:Citation Style 1

This is an old revision of this page, as edited by Lowercase sigmabot III (talk | contribs) at 05:44, 11 May 2017 (Archiving 1 discussion(s) from Help talk:Citation Style 1) (bot). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Archive 25←Archive 30Archive 31Archive 32Archive 33Archive 34Archive 35

{{cite bioRxiv}}

Could someone help create this?

Basically, it should be very similar to {{cite arXiv}}, except without the "fill this with a bot" code. That is, the supported parameters should be

  • |authors= and variants
  • |date= and variants
  • |title=
  • |biorxiv=
  • |doi= should throw an error, telling people to use |biorxiv= without the '10.1011' part of the doi. If a valid doi that doesn't start with 10.1011 is used, the message should invite users to instead use {{cite journal}}.
  • All other identifiers and parameters should be unsupported.

Headbomb {talk / contribs / physics / books} 17:09, 16 February 2017 (UTC)

Hi Headbomb, I'm not sure I understand the added value of these specific templates… Isn't it enough to use the |biorxiv= parameter with an existing CS1 template? The same holds for citeseerx below. − Pintoch (talk) 17:44, 16 February 2017 (UTC)
This, like {{cite arxiv}} would do two things. It specifically identifies the publication as a preprint, and which would facilitate the bot-maintenance of these templates and general cleanup of the citations. Right now, there's a lot of people doing citations to biorxiv preprints like this (the first is done by putting the URL in the reftoolbar and letting the gadget complete it
  • Navarrete, Israel; Panchi, Nancy; Kromann, Peter; Forbes, Gregory; Andrade-Piedra, Jorge (15 February 2017). "Health quality of seed potato and yield losses in Ecuador". bioRxiv. p. 108712. doi:10.1101/108712.
Which is not how bioRxiv preprints should be cited. They should be cited as
  • Navarrete, Israel; Panchi, Nancy; Kromann, Peter; Forbes, Gregory; Andrade-Piedra, Jorge (15 February 2017). "Health quality of seed potato and yield losses in Ecuador". bioRxiv 108712. {{cite web}}: Check |biorxiv= value (help); Missing or empty |url= (help)
You might argue that this can be already be achieved with existing templates like {{cite web}} and {{cite journal}}, but using those templates misleads people into filling unnecessary and undesired parameters.
And if you try letting citation bot expand the doi in a cite journal, you get
This seems to be generalized to all biorxiv dois, but might be a temporary database issue. However, I have no faith that the crossref information would not polute the citation with extraneous and unecessary information, like putting CSHL as the publisher, biorxiv as the journal, and similar. It would also highjack the doi parameter which should be used for the official version, once published. Headbomb {talk / contribs / physics / books} 17:58, 16 February 2017 (UTC)
Makes sense, thanks for the explanation! − Pintoch (talk) 18:12, 16 February 2017 (UTC)
@Pintoch, Trappist the monk, and Jonesey95: can any of you code this? I would, but I know nothing of LUA. I could hack something via an invocation of cite web, but I'd rather not. Headbomb {talk / contribs / physics / books} 12:18, 22 February 2017 (UTC)
Of course, but is there consensus to add yet two more cs1 templates with attendant error messages and categories, documentation, etc?
If the decision is taken to create these templates as cs1 templates, there is a side benefit in that it will force me to finally do the unsupported arXiv parameter test properly because these two templates will require the same sort of error detection.
—Trappist the monk (talk) 12:28, 22 February 2017 (UTC)
The only argument against them really is "but that's more templates to deal with", and I think I've shown pretty conclusively that using the existing ones create lots of issues in the long term, while lots of benefits would come from a dedicated template like {{cite arxiv}}. We might need a {{cite SSRN}} too, but I haven't looked into them much. Headbomb {talk / contribs / physics / books} 12:34, 22 February 2017 (UTC)

Any progress on this? Headbomb {talk / contribs / physics / books} 16:37, 1 March 2017 (UTC)

@Trappist the monk:? Headbomb {talk / contribs / physics / books} 09:41, 22 March 2017 (UTC)
Is there a consensus to add this template to cs1? Of all the editors who monitor this talk page (234 at this writing) only three have had anything to say here. If I read this topic correctly, you are the only editor who has expressed support for it.
—Trappist the monk (talk) 13:51, 22 March 2017 (UTC)
{{cite arxiv}} exists, this one (as well as {{cite citeseerx}}) is no different. I have shown a need for it, and no one objects. We don't need RFCs for every single incremental upgrade to the CS1 suite of templates. The only reason I haven't created it myself is because I can't write in LUA. I could have half-assed a {{cite journal}} wrapper for it, and only allow a few basic parameters, but I'd much rather have proper support from the start go. Headbomb {talk / contribs / physics / books} 14:41, 22 March 2017 (UTC)

Created. Both need documentation which I shall leave to others.

—Trappist the monk (talk) 16:52, 26 March 2017 (UTC)

Thanks! We might need a {{cite SSRN}}: Empty citation (help) in the future, but right now I don't understand the SSRNs system well enough to be sure that it's needed, or what should or shouldn't be allowed for parameters if there is a need for it. I'll be focusing on biorxiv/citeseerx cleanup for now (and I'll create documentation for them later this week). Headbomb {t · c · p · b} 08:50, 27 March 2017 (UTC)


@Trappist the monk: When using {{Cite biorxiv | last1 = Goldberg|first1 = Amy |display-authors=etal. |year=2016 |title=Familial migration of the Neolithic contrasts massive male migration during Bronze Age in Europe inferred from ancient X chromosomes|biorxiv=078360}}, the title gets italicized.

  • Goldberg, Amy; et al. (2016). "Familial migration of the Neolithic contrasts massive male migration during Bronze Age in Europe inferred from ancient X chromosomes". bioRxiv 078360. {{cite bioRxiv}}: Check |biorxiv= value (help)

It should be put in quotes. Similarly, |journal= seems to be allowed (see above for the list that should be allowed), and it shouldn't be. There the . at the end of the citation can also appear on a different line, but that may be a wider issue related to access locks and dots.Headbomb {t · c · p · b} 02:36, 8 April 2017 (UTC)

{{cite biorxiv}} does not yet exist; {{cite biorxiv/new}} does:
{{Cite biorxiv/new | last1 = Goldberg|first1 = Amy |display-authors=etal. |year=2016 |title=Familial migration of the Neolithic contrasts massive male migration during Bronze Age in Europe inferred from ancient X chromosomes|biorxiv=078360}}
Goldberg, Amy; et al. (2016). "Familial migration of the Neolithic contrasts massive male migration during Bronze Age in Europe inferred from ancient X chromosomes". bioRxiv 078360. {{cite bioRxiv}}: Check |biorxiv= value (help)
this is true because the live module does not yet support {{cite biorxiv}}; still waiting for template documentation.
—Trappist the monk (talk) 03:01, 8 April 2017 (UTC)
Ah I see. I was waiting for it to go live before creating the doc, but I suppose I could do that now. Headbomb {t · c · p · b} 03:11, 8 April 2017 (UTC)
Done. I hope I haven't screwed up. Headbomb {t · c · p · b} 03:27, 8 April 2017 (UTC)

quick query from a by-stander: should the template output some sort of indication of the name of the website or the publisher of the website that's hosting these articles beyond the bioRxiv identifier number? I understand what it is from clicking on the ID number, but maybe we could give just an extra clue for our readers? Imzadi 1979 → 06:10, 8 April 2017 (UTC)

I suppose that's possible, but I based it on {{cite arxiv}}, which doesn't do that since website/publisher is obvious (it's the arxiv repository). Likewise for bioRxiv, it's hosted on the bioRxiv repository. The only difference between the two is bioRxiv is relatively new and only starting to pick up steam (at a very impressive rate too). The real question is how are bioRxiv entries usually cited in the literature? We should follow that, but I suspect biology treats them the same way as physics/astronomy treats arxiv citations. Headbomb {t · c · p · b} 14:28, 8 April 2017 (UTC)

Can anyone remember...

Can anyone know how to manage these templates for volumes with publication dates spread over multiple years? (they're unusual, but early 20th century works sometimes had publication dates of 1910-1913, for example). I've done it once before, but can't remember where! Any advice gratefully received... Hchc2009 (talk) 08:12, 10 April 2017 (UTC)

Real life examples are almost always useful. It saves us from the need to contrive examples.
I think that it is true that, generally, each of the the several volumes of a multi-volume source should be treated as a separate source. The cs1|2 templates are not designed to render the necessary bibliographic details for a single source. So, best practice is, I think:
{{cite book |author=Author |title=Title |chapter=Chapter |pages=100–110 |date=1910 |volume=1}}
Author (1910). "Chapter". Title. Vol. 1. pp. 100–110. {{cite book}}: |author= has generic name (help)
{{cite book |author=Author |title=Title |chapter=Chapter |page=78 |date=1911 |volume=2}}
Author (1911). "Chapter". Title. Vol. 2. p. 78. {{cite book}}: |author= has generic name (help)
{{cite book |author=Author |title=Title |chapter=Chapter |pages=204, 223 |date=1912 |volume=3}}
Author (1912). "Chapter". Title. Vol. 3. pp. 204, 223. {{cite book}}: |author= has generic name (help)
{{cite book |author=Author |title=Title |chapter=Chapter |pages=xxiv, 31–33, 354 |date=1913 |volume=4}}
Author (1913). "Chapter". Title. Vol. 4. pp. xxiv, 31–33, 354. {{cite book}}: |author= has generic name (help)
—Trappist the monk (talk) 10:47, 10 April 2017 (UTC)
Or, for a single volume with a publication date that spans multiple years:
{{cite book |author=Author |title=Title |chapter=Chapter |pages=100–110 |date=1910–1913 |volume=1}}
Author (1910–1913). "Chapter". Title. Vol. 1. pp. 100–110. {{cite book}}: |author= has generic name (help)
That should work. Note the en dash. – Jonesey95 (talk) 14:41, 10 April 2017 (UTC)

See Wikipedia talk:WikiProject Spam#amazon.com Headbomb {t · c · p · b} 11:56, 13 April 2017 (UTC)

Template:Cite IETF

Can something be done about this template?

  1. It has quite low use (according to User:Green Cardamom at Special:Diff/775225851, only 181 articles).
  2. It has bugs which are not easy to fix. i.e. |deadurl=no is ignored, plus |archiveurl= and |archive-url= are not the same. It uses Template:Citation/core instead of Lua module templates like Template:Cite web.
  3. Template:Cite web can do almost everything this template can do, including |rfc=.
  4. Documentation is outdated.

As an example, right now this template needs to use Template:Webarchive for the purpose of |archive-url=, seen in revision 775225151.

I'd like to see this IETF template go away, or be fixed of its bugs. Any other proposals or suggestions? 80.221.152.17 (talk) 23:59, 13 April 2017 (UTC)

According to Template:Citation/core, Template:Cite wikisource is also affected and most templates have been converted to use Module:Citation/CS1. It's used on 2362 articles as of today. 80.221.152.17 (talk) 00:12, 14 April 2017 (UTC)

Suggest open a WP:TfD with the above rationale (WP:TFD#REASONS #2). If it passes (for delete) I'll make a script for converting the 181. -- GreenC 02:26, 14 April 2017 (UTC)
No need for a TFD, 'just' update {{cite IETF}} to mirror {{cite web}}, map |section-name= to |title=, map |title= to |work=. Then add proper support for BCP, FYI, IEN, I-D, RFC, RTR and STD identifiers, with auto-url generation. I'd do it, but I can't do anything in LUA. Headbomb {t · c · p · b} 07:00, 14 April 2017 (UTC)
As far as I can tell (and I have not looked at all possible cases) {{cite ietf}} correctly applies Citation Style 1. The back-end, and/or the scripting language utilized, is not directly relevant to style issues in general, and to citing IETF docs in particular, at least per the current CS1 implementation. If this template has bugs that trouble you and/or bad documentation that also troubles you, by all means fix them. Converting it to a CS1 template is another topic. As for {{cite wikisource}}, this discussion is not applicable. It is not a CS1 template, nor should it necessarily be one. 65.88.88.75 (talk) 18:17, 14 April 2017 (UTC)

|coauthor= and |coauthors= are dead

Cite book comparison
Wikitext {{cite book|author=Author|coauthor=Coauthor|title=Title}}
Live Author. Title. {{cite book}}: |author= has generic name (help); Unknown parameter |coauthor= ignored (|author= suggested) (help)
Sandbox Author. Title. {{cite book}}: |author= has generic name (help); Unknown parameter |coauthor= ignored (|author= suggested) (help)

We deprecated |coauthor= and |coauthors= sometime in late 2013 to early 2014. These two parameters contributed the vast majority of pages to Category:Pages containing cite templates with deprecated parameters. Except for eight stubborn pages (see separate discussion at WP:VPT), the category is now empty.

In the whitelist sandbox I have disabled the two parameters and will cleanup the supporting code in a bit.

—Trappist the monk (talk) 13:49, 16 April 2017 (UTC)

At the WP:VPT conversation, Editor Jonesey95 has suggested that cs1|2 stop using Category:Pages containing cite templates with deprecated parameters and instead use Category:CS1 errors: deprecated parameters. I agree with this suggestion. The current name is too long; the proposed name is in keeping with the majority of subcategory names in Category:CS1 errors. Without objection, I shall make the necessary changes to implement this suggestion. Now is a good time since the category is more-or-less empty.
—Trappist the monk (talk) 15:07, 16 April 2017 (UTC)
I think that all support for |coauthor= and |coauthors= has been removed from the module sandboxen. I have changed the deprecated parameter category name. After we take the module sandboxen live (we ought to do that, it's been a while) Category:CS1 errors: coauthors without author can be deleted along with its supporting help text at Help:CS1 errors. Similarly, the new deprecated parameter category needs to be created and the help text pointed to it.
—Trappist the monk (talk) 15:58, 16 April 2017 (UTC)

Cyrillic URLs

{{Cite web}} generates a warning when a (valid) URL is in Cyrillic (and, I suspect, in any other non-Latin script), which it probably shouldn't, since there is nothing wrong with the URL. An example of this behavior can be seen here. Can someone please take a look into this?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); April 17, 2017; 17:48 (UTC)

Instructions for converting the URL to Roman characters are available via the "help" link in the error message. – Jonesey95 (talk) 18:00, 17 April 2017 (UTC)
I'm aware of that. The point is that there is no need to convert the characters, since the original URL is perfectly valid (and more readable).—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); April 17, 2017; 18:03 (UTC)
Previous discussion.
As far as I know, DNS domain names must still be Latin characters. Unless the standard has changed, I suspect that what is happening is that your browser is now capable of translating хвастовичский-район.рф to its Punycode value (xn----7sbbfb0baicf2bdizhdn4c5b.xn--p1ai) to be usable by DNS but render's a Unicode version for the reader. If I drop the Punycode version of the url into my browser's address bar, I get the correct web site and my browser renders the Cyrillic domain name.
—Trappist the monk (talk) 18:46, 17 April 2017 (UTC)
Thanks. I was looking for previous discussions, but must have missed that one.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); April 18, 2017; 13:27 (UTC)

Access locks on paywalled links: lock color and hover text

We have some access-lock images which are occasionally used to indicate whether a source is paywalled or not. One of them is File:Lock-red.svg. It's bright red (), with a transparent background. The {{cite journal}} source code uses it to indicate paywalled sources.

I don't like the bright red. Why? Because, as Mark viking pointed out six months ago,[1] many paywalled sources let you read the abstract for free, or a page or two for free. Please correct Mark and I if we're wrong, but we think that bright red may imply "you can't read any of this for free". This may mislead our readers, and dissuade them from clicking through and reading abstracts for free.

I think that we should use some color other than bright red.

We could use dark red (like this). And then we could add a white background or white border, to make sure that users reading Wikipedia on a black background would get sufficient contrast. In fact, if you look through the file history of Lock-red.svg, you'll see that it used to be dark red, until it changed to light red this past September.

Or we could use gray (on a transparent background), or black (on a white background), or any other color.

Thoughts?

Kind regards, —Unforgettableid (talk) 02:30, 22 February 2017 (UTC)

The dark red fails one of the criteria we established for the icon designs, to wit: contrast against both white and black backgrounds. This is important for the visually impaired and for those who invert their colors (light text on a dark or black background).
As part of the initial discussions I proposed a series of icons that were all blue; access indicated by the lock shape only. That idea was shot down because others believed that multiple indications of access (shape and color) are better than the single (shape alone).
Before continuing this conversation, might I recommend that you spend some time in the archives of this page reading the discussions that got us to where we are today? I think that the bulk of it begins in Archive 22.
—Trappist the monk (talk) 03:54, 22 February 2017 (UTC)
Dear Trappist: The problem with the old dark-red access lock icon is that it had a transparent background. This made it nearly invisible when the icon was superimposed upon a black webpage. I see four possible workarounds: A) Underlay a white rectangle beneath the dark-red lock. B) Or a white rounded rectangle. C) Or a white oval. D) Or add a thick white outline to the dark-red lock. Even three or four pixels thick, if you want. —Unforgettableid (talk) 02:51, 23 February 2017 (UTC)
Sure, those are work-arounds. But, neither you nor I have the power to change that which was decided by RFC, do we? Without another RFC that overrides the current consensus, the access signals shall have the forms and colors that were determined by the visual design RFC.
—Trappist the monk (talk) 03:56, 23 February 2017 (UTC)
In that RFC, Headbomb offered a choice of multiple colors for the free-access lock and the partial-access lock. But the only color choice he offered for the paywall lock was bright red. (In other words, bright red was the only choice available on the ballot.) Because the ballot offered no choice in the matter, I believe it might be inaccurate to say that the RFC participants agreed to make it bright red. I believe it'd be more accurate to say that the lock ended up bright red by default. —Unforgettableid (talk) 04:27, 23 February 2017 (UTC)
Only one color was offered for the free access lock, green. The only one where there was a choice was the partial access lock, yellow vs blue which left very few people happy. I personally believe Green/Grey/Red will gain support the next time we ask, but it's possibly Green/Grey/Grey will get it too. Green/Blue/Red is a a truly ridiculous scheme that makes zero sense, and people only went for it because the yellow was felt 'not yellow enough' or WP:ACCESS unfriendly. Headbomb {talk / contribs / physics / books} 04:54, 23 February 2017 (UTC)
Look also at the post timestamped at "22:42, 10 February 2017 (UTC)" on this page for possible alternatives, some of which include gray. Headbomb {talk / contribs / physics / books} 12:17, 22 February 2017 (UTC)
That gray is fine, though I still suspect that I prefer dark red. —Unforgettableid (talk) 02:51, 23 February 2017 (UTC)
The dark red would still violate WP:ACCESS. Headbomb {talk / contribs / physics / books} 04:46, 23 February 2017 (UTC)
I've thought of some possible workarounds, and described them, in a comment which you probably haven't read yet. Search through this page for the phrase [ four possible workarounds ] if you'd like to learn about them. I believe that, with the workarounds, dark red is a viable option. —Unforgettableid (talk) 05:52, 23 February 2017 (UTC)
Those aren't viable workarounds. A white rectangle underneath the lock for instance, would look downright awful and be very distracting. Likewise for the other choices. Headbomb {talk / contribs / physics / books} 10:29, 23 February 2017 (UTC)
A) How about a thin white outline, perhaps one pixel thick or a few pixels thick? B) What percent of our readers view Wikipedia on a black background? I suspect that it's a tiny percentage. Shouldn't we care more about making things look nice for the majority than for the minority? —Unforgettableid (talk) 14:39, 24 February 2017 (UTC)
The colors and shapes of the access signals lock was decided by the visual design RFC. Must I repeat myself? Neither you nor I have the authority to arbitrarily overturn such a decision. The number of readers who use an inverted color scheme is irrelevant; those who do deserve to be accommodated if it is possible to do so.
—Trappist the monk (talk) 11:17, 8 March 2017 (UTC)
One thing we could possibly add to the hover text is "Paid subscription required, abstract or excerpt may be available" instead of just "Paid subscription required". Headbomb {talk / contribs / physics / books} 12:44, 22 February 2017 (UTC)
Dear @Headbomb: Good idea. In fact, maybe we could provide even more alt text than that. Perhaps this: "A summary or excerpt may be available for free. However, to read the full text, you must either buy access or visit a library with a paid subscription. Try phoning your nearest university library." In addition, perhaps we could even add a dotted underline and a fancy cursor. border-bottom: 1px dotted #000; cursor: help; This would help readers realize that there's useful alt text, and that they should wait a second for it to appear. You can see a live preview of the full package at this link. —Unforgettableid (talk) 02:51, 23 February 2017 (UTC)
That is a ridiculously long message. 'Paid subscription required, abstract or excerpt may be available' covers all of that. I'm not against the cursor/underlining though. Headbomb {talk / contribs / physics / books} 04:45, 23 February 2017 (UTC)
Both you and I have been to university. Also, both you and I both know that we can get free online access to many papers at a university library. But many laypeople don't know this. In fact, even some university graduates don't know this. For those in the know, we're wasting their time by writing so much hover text. But these people can quickly learn what the paywall lock means. They can read the hover text once, understand it, and never feel a need to hover their mouse over a paywall lock ever again. But, for high-school students and other individuals not in the know, we may be opening their eyes (maybe for the first time ever) to vast trove of scholarly knowledge. —Unforgettableid (talk) 06:09, 23 February 2017 (UTC)
It's not a matter of having been to university or not, it's a matter of the message being exceedingly long. This is a message that will need to be read by screen readers several times per article, and thus needs to be short. This is why all the messages are short and to the point, e.g. "Free registration required" instead of "You are required to register to read this article, but it does not cost money to do so. Websites will typically asks for your email and some personal information. You could also ask a friend to register for you, or register with a dummy email if you do not trust the website with your personal information, however this may violate their terms of service. Your password and login information might be stored in a cookie. That being said, an excerpt might still be available to unregistered users."
"Paid subscription required" implies a subscription is required to have access to the full version; it doesn't matter if it's yours, your supervisor's, your friend's or the library's institutional subscription. If you have short wordings, those could be suitable however. But they need to be short, e.g. "Paid or library subscription required, free abstract or excerpt may be available". Headbomb {talk / contribs / physics / books} 10:29, 23 February 2017 (UTC)

Ah OK fair. Your point about screen readers is a good one. Indeed, I looked into the matter just now; and it turns out that screen readers will indeed read out the image's title text in this case. (Source.) And your little speech discussing dummy emails and cookies made me laugh. :) How's this?: "Paid or library access required; but a summary may be available for free. Click for help." —Unforgettableid (talk) 19:05, 23 February 2017 (UTC)

Locks aren't currently clickable and aren't linked to anything. Where would clicking on the lock take people? Headbomb {talk / contribs / physics / books} 19:29, 23 February 2017 (UTC)
There need not be anything clickable for a title= attribute to be used; it is valid on most HTML elements since HTML 4.00, and all elements from HTML5 onward. From the HTML 4.01 spec:

Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers frequently display the title as a "tooltip" (a short message that appears when the pointing device pauses over an object). Audio user agents may speak the title information in a similar context.

Try hovering your mouse here. --Redrose64 🌹 (talk) 20:09, 23 February 2017 (UTC)
Re "There need not be anything clickable". The proposed message has "click for help". That's what I'm referring to. Headbomb {talk / contribs / physics / books} 20:38, 23 February 2017 (UTC)
Clicking on the paywall lock could take readers to Wikipedia:Find your source. Would this work? —Unforgettableid (talk) 14:48, 24 February 2017 (UTC)
MediaWiki copies the image's alt= attribute text into the title= attribute. No need to muck with title= attributes and no need for the image to be clickable.
—Trappist the monk (talk) 20:17, 23 February 2017 (UTC)
Not true: consider the twelve images in Headbomb's post of 22:42, 10 February 2017 (UTC) beginning "No, we unrestrict their use on identifiers and urls" in the section #Whatever happened to the access lock RFCs? - here, all twelve images have the alt= attribute, and none of them have a title= attribute. --Redrose64 🌹 (talk) 21:58, 23 February 2017 (UTC)
I think that we are both mistaken. Your mistake: none of those twelve images have alt= attributes – though some have 'alt' in their name:
[[File:Lock-blue-alt-2.svg|9px]] →
My mistake: MediaWiki does not copy alt= into title=. Rather, it is done in Module:Citation/CS1/Configuration where the lock images are defined like this:
[[File:Lock-green.svg|9px|link=|alt=Freely accessible|Freely accessible]] → Freely accessible
where the text to the right of the pipe is assigned to the title= attribute.
—Trappist the monk (talk) 23:09, 23 February 2017 (UTC)
They do have alt= attributes. Use your browser's "View page source" feature. Search for the text <img alt="Lock-green.svg" src="//upload.wikimedia.org/wikipedia/commons/thumb/6/65/Lock-green.svg/9px-Lock-green.svg.png" You should find six instances, other than the one in this post. All six are identical: the <img /> tag has seven attributes, being (some values replaced with an ellipsis for clarity) alt="Lock-green.svg" src=... width="9" height="14" srcset=... data-file-width="512" data-file-height="813". There is an alt= attribute; there is not a title= attribute. The enclosing <a href="/https/en.wikipedia.org/wiki/File:Lock-green.svg" class="image">...</a> element doesn't have a title= either. --Redrose64 🌹 (talk) 01:33, 24 February 2017 (UTC)
So they do. MediaWiki copies the image file name into the alt= attribute. Better that than nothing I suppose.
—Trappist the monk (talk) 11:12, 24 February 2017 (UTC)

The documentation implies that Links inserted by identifiers such as |doi= are not expected to offer a free full text by default So I am expecting the subscription will be set to yes by default if one of these is set. But it isn't. Hawkeye7 (talk) 21:20, 10 March 2017 (UTC)

If you mean that the template sets |subscription=yes if |doi= or other identifier is set, then no, that does not happen. The problem with |subscription= is that it doesn't specify which external link, |url= or one of the identifiers – there can be multiples – requires the subscription. As the code stands now, it assumes, correctly, that most identifiers (like |doi=) rarely offer free access to the source. We do not highlight the norm. When |doi= refers to a source that is free-to-read, editors may add |doi-access=free to highlight that identifier. There are exceptions: a couple of identifiers are automatically flagged because it is known that these identifiers are always free-to-read (|arxiv=, |rfc=, etc). In the same sense, |url= and |chapter-url= and their aliases are assumed to be free-to-read. Again, we don't hightlight the norm but when these are not free-to-read, editors may set |url-access=subscription, etc.
—Trappist the monk (talk) 21:48, 10 March 2017 (UTC)
But a |doi= card does not trigger a "subscription required" note, nor does a |jstor= card; so |doi-access=free is the default. Hawkeye7 (talk) 23:07, 10 March 2017 (UTC)
What is card?
No, |doi-access=free is not the default because we do not highlight the normal state, either with an icon or with text. For most identifiers the links normally link to sources behind a registration or subscription wall. Because of this, there is no need to clutter the rendered citation with extraneous access signals.
—Trappist the monk (talk) 23:17, 10 March 2017 (UTC)

"|registration=yes" and "|subscription=yes" rendering is awful

(Sorry to add this new section not at the end of the page, but it's related to the one above.)

I brought this up awhile back, but didn't have time to pursue it further then. I'll quote here my main points from before:

I was just editing an article where one of the citations required (free) registration to read, so I looked at the {{cite web}} template and found there was a "|registration=yes" parameter, so I added that. However, it renders so poorly and confusingly for readers -- "(registration required (help))." with the help tooltip giving "Sources are not required to be available online. Online sources do not have to be freely available. The site may require registration." -- that I reverted my change and just added "(Registration required.)" at the end of the <ref> manually.
First off, the "r" in "registration" should be capitalized if there's a period at the end, and the period should go inside the parentheses, not outside. Secondly, "Sources are not required to be available online. Online sources do not have to be freely available." must be very confusing to the average reader. I don't think it's helpful to the average reader to obliquely define Wikipedia reference inclusion policy in the help for what the tag means. Finally, why the weasel words in "may be required"? The parameter says "registration=yes", and it renders as "registration required" -- the "may be" has no business being there.

And the same is true for "|subscription=yes". Thank you, Trappist the monk, for pointing me to where I would need to make my suggested changes. I have just edited Module:Citation/CS1/Configuration/sandbox to change:

(registration required (<span title="Sources are not required to be available online. Online sources do not have to be freely available. The site may require registration." style="border-bottom:1px dotted;cursor:help">help</span>))

to:

(Registration required (<span title="The site requires registration to access this page." style="border-bottom:1px dotted;cursor:help">help</span>))

and:

(subscription required (<span title="Sources are not required to be available online. Online sources do not have to be freely available. The site may require a paid subscription." style="border-bottom:1px dotted;cursor:help">help</span>))

to:

(Subscription required (<span title="The site requires a paid subscription to access this page." style="border-bottom:1px dotted;cursor:help">help</span>)

I see that the period after the ")" gets added elsewhere, and may be done in such a way that it would be difficult to omit it for registration=yes and subscription=yes so that the period can be placed inside the parentheses in the above text, so I have not yet looked into that. Before I do, I wanted to see what the reaction was to my suggested changes and the logic behind them. Thank you. --Dan Harkless (talk) 01:26, 14 April 2017 (UTC)

I guess I wouldn't worry too much about the separator character. If one is to believe the outcome of this rfc, then both |subscription= and |registration= will be going away.
—Trappist the monk (talk) 12:32, 14 April 2017 (UTC)
I wouldn't believe the outcome of that rfc. Its conclusions, well-meaning as they are, are self-contradictory: aspect B1 allows all locks ("the editorial discretion of individual Wikipedians should be allowed and supported"), but aspect B3 imposes them by not offering any other alternative ("the editorial discretion of individual Wikipedians should be allowed and supported"). 65.88.88.126 (talk) 14:33, 17 April 2017 (UTC)
Flagging would be allowed, whether to do so or not would be up to editor's discretion. There's no contradiction. Headbomb {t · c · p · b} 14:58, 17 April 2017 (UTC)
Using the facilities of CS1, I would like to not use locks as allowed to, but I would like to flag access requiring subscription, as also allowed to. Any ideas? 65.88.88.126 (talk) 16:08, 17 April 2017 (UTC)
The access of what is the question. URLs? arXiv links? DOIs? JSTOR identifiers? Simply appending "subscription required" at the end of the citation is ambiguous. How would you like things rendered? Do you have a mockup? Headbomb {t · c · p · b} 16:24, 17 April 2017 (UTC)
Not what I am asking. The exact placement or wording of the flag to be applied is not relevant to my question. All I want to be able to do is to signal subscription requirement, but without using locks. It seems that locks are locked in when it comes to this. If that is the case, the RFC close mis-informs, possibly because the RFC itself did not clarify that subscription/registration access flags are apparently dependent on the lock scheme. Aspect B3 may not be independent, but a sub-aspect of Aspect B1. Something like this should have been pointed out, as it may have been material to the RFC's consideration. 65.88.88.126 (talk) 18:08, 17 April 2017 (UTC)
Then what you would like is not a viable or sustainable option. The reasons have been explained to you, and the community agrees on this. Headbomb {t · c · p · b} 18:11, 17 April 2017 (UTC)
And my point is that the community was presented with a partly false or incomplete set of options. Aspect B3 was not fully explained as dependent on Aspect B1. This may have affected the outcome. It certainly affected the closing, and the closer's comments, which seem contradictory as indicated above. 65.88.88.69 (talk) 19:51, 17 April 2017 (UTC)
Again, those are not contradictory, and does not hinge on locks being their or not. People could decide to go text-based, with arxiv:1234.1234 (Free to read), doi:10.1234/whatever (Subscription Required), JSTOR(Registration required). Headbomb {t · c · p · b} 19:58, 17 April 2017 (UTC)
You will notice that what I wrote, included a caveat. The RfC closer wrote:

There is,however, a greater issue: A significant body of opinion has been expressed below that the entire visual status indicator idea is not acceptable. The above assessment must be interpreted in light of this. I would urge that this close is treated as a tentative indication of how the Citation Template processing would work in a new RfC to see if there is significant buy-in to proceed forward. To move forward with the shaky consensus established below would not comport with WP:CONS. Overall, there is not yet significant consensus on implementation of these citation template behaviors.

This I believe leaves us in some sort of limbo. When previously I asked how we should proceed, I don't think that I got a compellingly definitive answer. There are those who believe that we should revert all of the access-signal-related changes; there are those who believe that we should implement the individual aspects of the RfC that received consensus no matter how slight; there are those who believe that, for now, we should do neither of those things and continue with the status quo pending supplementary RfCs. I find myself in this latter camp because of closer's writing quoted above and because the status quo version of access-signal support is already out there in use and has been since 29 October 2016.
—Trappist the monk (talk) 15:38, 17 April 2017 (UTC)

Way to override |title requirement, or to replace title with a description?

Hey, I hope this is the right place. I was wondering if there was a way to use, say {{cite journal}} without having a title? Sometimes I need to cite pieces in academic journals that don't have a title, per se. The most obvious example of this is a book review, which generally would be cited as [Review of such-and-such a work], where in lieu or or alongside any proper title is a description of the work itself; and titles and descriptions are distinguished in formatting. Right now I just have |title=[Review of such-and-such], but that creates the unsightly "[Review of such-and-such]". And if there is a proper title and a description, then it would have to end up as "Author X has done it again [Review of such-and-such]". For examples of this latter type, see this example from APA 6:

  • Schatz, B. R. (2000, November 17). Learning by text or context? [Review of the book The social life of information, by J. S. Brown & P. Duguid]. Science, 290, 1304. doi:10.1126/science.290.5495.1304
  • "If the review is untitled, use the material in brackets as the title; retain the brackets to indicate that the material is a description of form and content, not a title."

And these examples from CMoS 16 (the first two as notes, the third as a bibliography entry):

  • Ben Ratliff, review of The Mystery of Samba: Popular Music and National Identity in Brazil, by Hermano Vianna, ed. and trans. John Charles Chasteen, Lingua Franca 9 (April 1999): B13–B14.
  • David Kamp, “Deconstructing Dinner,” review of The Omnivore’s Dilemma: A Natural History of Four Meals, by Michael Pollan, New York Times, April 23, 2006, Sunday Book Review, http://www.nytimes.com/2006/04/23/books/review/23kamp.html.
  • Sorby, Angela. Review of Songs of Ourselves: The Uses of Poetry in America, by Joan Shelley Rubin. American Historical Review 113 (April 2008): 449–51. doi:10.1086/ahr.113.2.449.

Does this make sense? Is there a way to not have a title (i.e., something that is surrounded with quotation marks) and instead (or in addition) have a description? Thanks! Umimmak (talk) 21:52, 18 April 2017 (UTC)

Aesthetics are not the main concern when it comes to citing claims. What if a citation looks good but is illegible or obtuse? In any case, almost all serials that review works with some regularity have a "Reviews" column, section, or department. You can use |department=Reviews or similar. Additionally, you have to include the information that will help others easily discover the source: if the review has a title, you should use that title - or at least as much of the title as would be required to make it a legible, discoverable citation. If the review's title is the title of the reviewed work, then use that. Hopefully, helped by the rest of the citation, the context will be obvious to the average reader. 65.88.88.126 (talk) 22:36, 18 April 2017 (UTC)
Previous discussion such as it was ... I don't know of any other
—Trappist the monk (talk) 23:00, 18 April 2017 (UTC)
Perhaps a |descriptive-title=yes option would work, turning off the default quotation marks around a news or journal article title? Imzadi 1979 → 23:21, 18 April 2017 (UTC)
Yeah perhaps, although what happens when you need both a title and a description? Umimmak (talk) 11:51, 19 April 2017 (UTC)
We had a brief discussion on it in the context of cite interview, which cites a discussion from archive 5. --Izno (talk) 23:27, 18 April 2017 (UTC)
Of the three examples provided by Editor Umimmak, in each case, I think I can find a title and so can construct three cs1 templates:
For Shatz, the term 'review' does not appear on the linked page though the actual article may use it. For this reason I left out mention of that. In Kamp, because |department=Sunday Book Review pretty well describes the type of the article, I made |type=The Omnivore’s Dilemma: A Natural History of Four Meals, by Michael Pollan. Similarly, |department=Featured Reviews means that it is not necessary to describe the type and because the reviewed work's title in in the article title, no need to use |type=.
—Trappist the monk (talk) 23:59, 18 April 2017 (UTC)
But those three are wildly inconsistent and don't all provide sufficient information like the author and title of the reviewed work, which most style guides recommend. The Schatz example is a book review; it's in the "Books et al." section and the article has an info box with the publication details of the work in question. But only having the title "Learning by Text or Context?" doesn't provide information to the reader that it's a review of Brown & Duguid 2000.
For the Sorby review, the actual listed title is "Joan Shelley Rubin. Songs of Ourselves: The Uses of Poetry in America. Cambridge, Mass.: Belknap Press of Harvard University Press. 2007. Pp. 470. $29.95"; if you modify it, say, by removing extra information like the price, then you shouldn't surround it in quotes as it suggest that's the title.
And sometimes using |type= and sometimes using |title= for a description of the work (cf. the proposed templates for Kamp vs Sorby) seems wildly inconsistent. Umimmak (talk) 11:50, 19 April 2017 (UTC)
If Schatz is a review, then, |type=Review, problem solved. It is not the purpose of a citation to explain to reader what the cited content contains or describes. The purpose of a citation is to assist readers in locating the source that supports claims made in a Wikipedia article. If I go to the library and checkout the 17 November 2000 issue of Science and look in the table of contents, I likely won't find any reference to Brown & Duguid but I will find the title "Learning by text or context?" and that review's author. (Apparently not possible to directly link to that issue's TOC but a link to the TOC is available at the summary page).
The bibliographical details of Rubin's book are included in the review's title but to include them here only confuses the issue. Our reader does not need to have those details when seeking the review at the public library. I can imagine a reader checking the book for something that was written in the review because the book's bibliographic detail is the first thing he reads after the title. One can omit the reviewed work's bibliographic details as I did or hint at them with ellipses or include an editor's note: [bibliographic detail omitted]; in any of these cases the reader will be able to locate the review.
In none of the example templates that I constructed did I use |title= as a descriptor. In each case, the title of the review was supplied by the source and was obvious to me. I did not set out to be wholly consistent; that isn't my job here. I did set out to show how I think these three reviews might be cited; that I did them differently just shows that there are different possible methods. It is for you to impose consistency when you create citations in articles.
—Trappist the monk (talk) 12:58, 19 April 2017 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Help_talk:Citation_Style_1/Archive_32&oldid=779821955"