Help talk:Citation Style 1

Non-standard citation templates

This search finds templates whose names begin "Template:Cite...", that do not wrap one of the standard CS1 citation templates (currently finding 144 results). I've already upgraded all those that were straightforward, to do so. This give all the usual advantages, such as error trapping and embedded COinS.

I invite anyone interested and capable to look at upgrading the rest (or to consider whether they should be deleted, or merged - I nominated several such templates at TfD in recent days). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:42, 8 September 2016 (UTC)

You may be overreaching here. CS1 is a citation style. It is not a "standard". Just because a template attempts to cite something, does not mean it has to follow CS1, an unfinished spec to be sure. A more pertinent approach would be to fix meta- and specific-source templates that purport to be based on CS1 but either are not, or do so out of spec. 71.247.146.98 (talk) 11:56, 8 September 2016 (UTC)

Same thoughts here. If there are non-standard citation templates, it's probably for a reason. For example, some templates may reflect country-specific legal requirements for citing legal documents. At the very least, such changes should be first discussed on talk pages of the templates in question. — Kpalion^(talk) 12:29, 8 September 2016 (UTC)

[reply to both] Well, I didn't ask anyone to immediately "upgrade", I said "look at upgrading". And CS1 templates are more configurable in their presentation, thanks to |mode=, than anything hard-coded to a single presentation. After that, WP:BOLD applies; prior discussion is not mandated. if you have a list of "templates that purport to be based on CS1 but either are not, or do so out of spec", please feel free to link to it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:42, 8 September 2016 (UTC)

Editing is not the issue. Editing just to comply with a specific style is. Especially when the style is wrongly claimed a "standard". Write similar templates that apply your preferred style. Then let editors choose which iteration to use. There has been previous discussion here about CS1-based templates that need attention or de-categorizing. The relevant categories include several examples. 64.134.65.76 (talk) 17:36, 8 September 2016 (UTC)

Thanks for the advice; I don't find it compelling; not least because you wrongly refer to "editing just to comply with a specific style"; and misquote me. And if you/ the other editor (or are you the same?) want me to work on something else, I expect you to provide the link, not to send me to search for it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:22, 8 September 2016 (UTC)

Well your heading is "Non-standard citation templates". And this is a talk page for some citation templates (CS1), that you obviously exclude from the ones referred to in the heading, unless I'm mistaken. I don't think I misquoted. You mention "mode" but this is a CS1 parameter, and therefore not style-neutral. Also, I was not asking/telling you to work on anything, but laying out how things should be properly handled, imo. There are several subcategories in ‹The template Category link is being considered for merging.› Category:Citation Style 1 templates. There are templates in them that don't belong. To me that is a better approach, but I wasn't trying to convince anyone to do anything about it. 65.88.88.127 (talk) 21:24, 8 September 2016 (UTC)

The Times

It looks as though {{Cite newspaper The Times}} could be made a wrapper for {{Cite news}}. The former's |column= appears to be unused, while the rather unnecessary |day_of_week= is used only once. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:20, 8 September 2016 (UTC)

There seems to have been some lag in applying the tracking categories'; but those parameters still appear to be used on fewer than ten articles each. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:25, 8 September 2016 (UTC)

Looking at the documentation for {{Cite news}} it appears that |department= could be used for the name of a column; it could also be used for other areas within a newspaper, such as editorials. Jc3s5h (talk) 20:37, 8 September 2016 (UTC)

Now updated to max. 59 pages using |column=; max. 85 pages using |day_of_week=. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:15, 9 September 2016 (UTC)

Currently 118 page and 154 pages respectively. Andy, I think a lot more pages are using this template with those parameters than you think. Category population can be very slow when the job queue has high lag (you know that). Can you please wait until you are sure the categories are fully populated before doing anything. Previous discussion here (at the template talk page) is relevant. Also, you really should be pointing people to this discussion when they ask you what is going on. When Mjroots asked you here what was happening, your reply failed to point to this discussion, that is verging on misdirection. Your reply should have been along the lines of "I created the categories to help generate some statistics for the discussion I started where I am proposing to make this template a wrapper for cite news" (with a link to the discussion). @Iridescent: who I know has strong views on how this template should be used. Carcharoth (talk) 21:33, 9 September 2016 (UTC)

Now 136 pages and 194 pages respectively. It is clear that populating these tracking categories is going to take a long time. The transclusion count is 3017. Those that know how this template works and why it has 'column' and 'day of the week' parameters (The Times was published in a chapbook format for most of its history, hence this different citation style) know that most of the transclusions of this template will include use of these parameters, hence what Andy said above about the parameters being unused (or almost unused) makes no sense at all. I am going to ask at the technical village pump for advice here. Reversing the edits will just re-add to the job queue. Currently the issue is readers being served up with nonsensical category names as red-links (e.g. at Beckton Gas Works). I checked logged out, and readers are seeing those category names. I think we will need to create the categories and mark them as hidden, unless there is a way to 'hide' red-linked categories. Carcharoth (talk) 03:01, 10 September 2016 (UTC)

Short answer: no there isn't. Redlinked cats can never be hidden. --Redrose64 (talk) 07:47, 10 September 2016 (UTC)

Update: I have asked for advice here at the technical village pump. I wouldn't normally do this, but I think the issue needs some wider attention and I'll not be around for the next day or so. I'll add a similar note over at the template talk page. Carcharoth (talk) 03:24, 10 September 2016 (UTC)

@Carcharoth: No. When asked:

what is the purpose of these uncreated categories? The are appearing on all articles and lists that use this template.

My reply, was:

As the name indicates, they are TEMPORARY. One tracks TEMPORARY Cite newspaper The Times using the 'column' parameter; the other tracks TEMPORARY Cite newspaper The Times using the 'day of week' parameter.

There was no "misdirection" - borderline or otherwise - whatsoever. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:15, 10 September 2016 (UTC)

I fully understood what they did, but I asked what the purpose of the categories was. If there is to be a proposal to do away with {{cite newspaper The Times}}, I for one will be opposing it. Mjroots (talk) 14:25, 10 September 2016 (UTC)

Andy, your reply to Mjroots lacked information. You gave a literal reply (explaining what 'temporary' means) rather than pointing to this discussion. I think that omission of a link to this discussion is far from ideal. I apologise for saying it verged on misdirection. I think we should now focus on trying to work out when the 'temporary' categories will be fully populated. Currently the numbers are 260 and 356 respectively. I think we need the numbers to be stable for at least a full day before being confident that the categories have fully populated. On the wider question of the use of the parameters, I think they are only really useful before a certain date. After that date, The Times became a 'normal' newspaper. Not sure when that was though. Hopefully someone else will be able to provide that information. Carcharoth (talk) 09:16, 11 September 2016 (UTC)

File:Times May 10 1830.jpeg

Page 2 of The Times as it was formatted in 1830

Regarding the comments above from Carcharoth, it might make it easier to explain why citing early issues of The Times differs from other newspapers to see what it looked like in chapbook days. Each issue consisted of a single large sheet of paper, which was folded in half to create four nominal "pages". The front was filled with adverts, and the rear was filled with official notices (law reports, auction notices, births, marriages & deaths, stock prices etc), leaving only the two inner "pages" for actual news. These two pages (one shown to the right for illustrative purposes) were filled with very, very small type so as to cram everything in, and most headings in the same small type as a space-saving measure. Thus someone checking a reference who wants to find it in the original will effectively have to read 50% of the newspaper to find it since it will always be on page 2 or 3 so the page number isn't particularly useful, and there aren't 'headlines' in the modern sense for the eye to skim over. As a consequence, it's conventional when citing early issues of the Times to provide a column reference as well as the page, which as things stand the existing {{cite news}} template can't handle. Regarding when they stopped using this format, it was a gradual process; in the early 1830s they went from one sheet of paper to two (e.g. 8 pages per issue), circa 1850 they went to three sheets (12 pages), and circa 1860 they went to four sheets (16 pages) and started to abandon their formatting eccentricities (although not entirely; they stubbornly stuck to some conventions like "no news on the front page" until the late 1960s). ‑ Iridescent 13:49, 12 September 2016 (UTC)

My quick thoughts: keep the column indication as is, but drop the day of the week. I can't find it in the MOS now, but I recall reading that we don't include the day of the week in giving dates unless it's significant to the mention of the date in prose. As for including it in citations, I don't know of any style guide that includes it either. Imzadi 1979 → 17:37, 12 September 2016 (UTC)

Imzadi1979's proposal is acceptable to me. It'd be a bit less work for editors using the template, and a bot run could do the removal of the parameter from existing uses of the template. Mjroots (talk) 19:11, 12 September 2016 (UTC)

I'd agree with that. I suspect that "day of the week" field stems from the fact that the Sunday Times and Times have always had different editors and different editorial lines (and in some periods, different proprietors) yet are usually archived as a single entity. The other idiosyncratic field I'd be reluctant to lose from this template is "section", because the Times is both a general newspaper and an official gazette, it's sometimes important to make it clear if we're citing general editorial content or the formal paper-of-record stuff like the Law Reports or the Court Circular. ‑ Iridescent 20:12, 12 September 2016 (UTC)

The |section= could probably be mapped to the |department= of {{cite news}}. As for the day of the week, I have a random thought based on Iridescent said above: should the uses with dates that are Sundays give |work=The Sunday Times instead of |work=The Times? If so, that would retain the distinction while dropping the day of the week from date. Imzadi 1979 → 22:19, 12 September 2016 (UTC)

In late 2014, I made {{Cite newspaper The Times/sandbox}} that pretty much adheres to Editor Imzadi1979's suggestion:

"The Queen Mary Back In Port". The Times. No. 51269. London. 3 January 1949. col E, p. 4. template uses deprecated parameter(s) (help) – live

"The Queen Mary Back In Port". The Times. No. 51269. London. 3 January 1949. col E, p. 4. template uses deprecated parameter(s) (help) – sandbox

There are differences: period after the article title; |day_of_week= is ignored; |location= (not a parameter in {{Cite newspaper The Times}}) is in a different location as is |issue=.

—Trappist the monk (talk) 00:08, 13 September 2016 (UTC)

This all sounds good. Can anyone identify the uses of this template that are not using the day of the week parameter? Those will have to be checked to see if they are Sundays or not. Might also be worth looking around for other 'Sunday Times' citations elsewhere in Wikipedia and seeing if they are made distinct from 'The Times'. I am sure 'cite newspaper' has had this problem in the past with other newspapers with weekend editions. PS. I think the numbers are stable now - 1,274 for the column parameter and 2,935 for the day of the week parameter. Another check in a day or so should confirm that. Carcharoth (talk) 06:11, 13 September 2016 (UTC)

Re the Sunday Times, wouldn't it be simpler to create a separate template for that newspaper? Mjroots (talk) 07:55, 13 September 2016 (UTC)

Not necessarily. We can do something like this addition to the sandbox:

|newspaper={{#ifeq:{{{day_of_week|}}}|Sunday|Sunday Times|Times}}

which would do this:

"Steamer lost off The Lizard". The Times. No. 40718. London. 6 December 1914. col E, p. 4. template uses deprecated parameter(s) (help) – live

"Steamer lost off The Lizard". The Times. No. 40718. London. 6 December 1914. col E, p. 4. template uses deprecated parameter(s) (help) – sandbox

If this is not a good way to distinguish the Sunday edition, then yeah, a separate template will answer.

—Trappist the monk (talk) 11:24, 13 September 2016 (UTC)

Undone per this discussion.

—Trappist the monk (talk) 10:24, 17 September 2016 (UTC)

The discussion above is leaning towards the abolition of the day parameter, so a separate template would seem to be the way to go. Mjroots (talk) 09:43, 14 September 2016 (UTC)

No need for a separate template. It's what |newspaper= is for. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:11, 14 September 2016 (UTC)

Moving forward

Do we have consensus to make {{Cite newspaper The Times}} a wrapper for {{Cite news}}? We could need to add |column= to the latter, and deprecate |day of the week=, unless it is set to "Sunday", in which case it would change the value of |newspaper=. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:51, 16 September 2016 (UTC)

Yes, but if and only if {{cite news}} can handle the existing "section" parameter; because parts of the Times have official status, it can be important to note whether something appeared in the Law Reports (in which case will be treated as a legal precedent under the English common law), the Court Circular (the official record of the lives of the posh) or if it was just editorial opinion. ‑ Iridescent 18:57, 16 September 2016 (UTC)

See the suggestion to use |department=, above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:44, 16 September 2016 (UTC)

I'd prefer the creation of a separate template for the Sunday Times, as there were occasions when The Times was published under that title on a Sunday. Agree that we can do away with the day of the week, but the column must stay. Mjroots (talk) 08:40, 17 September 2016 (UTC)

I have undone the change to the sandbox that used |day_of_week=Sunday to modify the paper's name. We can attend to a separate template when and if this template change is put to bed.

—Trappist the monk (talk) 10:21, 17 September 2016 (UTC)

A separate template would still leave us with more, not less, to maintain. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:09, 17 September 2016 (UTC)

The sandbox vs live with |section=Section Name:

"Article Title". Section Name. The Times. No. 12345. London. 3 January 1949. col N, p. 2. template uses deprecated parameter(s) (help) – live

"Article Title". Section Name. The Times. No. 12345. London. 3 January 1949. col N, p. 2. template uses deprecated parameter(s) (help) – sandbox

—Trappist the monk (talk) 10:21, 17 September 2016 (UTC)

@Pigsonthewing: and Trappist the monk - it would appear that there is consensus. Can these changes be enacted and the temp categories be deleted please? Mjroots (talk) 18:58, 28 September 2016 (UTC)

As I indicated above, we should not have a separate template for the Sunday Times. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:56, 28 September 2016 (UTC)

For the record, as I write this, the counts of pages in the two temporary categories were:

‹The template Category link is being considered for merging.› Category:TEMPORARY Cite newspaper The Times using 'column' parameter – 1,287

‹The template Category link is being considered for merging.› Category:TEMPORARY Cite newspaper The Times using 'day of week' parameter – 2,990

I have replaced the live version of {{cite newspaper The Times}} with the sandbox version. The new live version also supports these standard cs1|2 parameter names as aliases:

|page= for |page_number=

|pages= for |page_numbers=

|department= for |section=

I have deleted the categories.

—Trappist the monk (talk) 20:18, 28 September 2016 (UTC)

Citation templates for Archival holdings and Manuscripts

Archival holdings and manuscripts are usually primary sources, but sometime there is the need to cite them (or give them as additional reference). For these sources is not possible to use CS1 because it doesn't have parameters for institution/repository, collection, file/box/shelf of the physical item cited, which are the mandatory way to identify such unique physical items. A short guide to quote manuscripts is here [1], and for archives is here [2] but there is a full literature on the subject.

A template for manuscript doesn't exist. There is the nice template {{Cite archive}}, which may be used also for manuscripts, but it is not integrated in the CS1. Is it possible to integrate it under the CS1?A ntv (talk) 15:17, 2 October 2016 (UTC)

CS1 is a style, so I assume that by "integration" you mean style-conformance. This can be done without a common code base, or ever touching any of the CS1 modules. All that is needed to render output in CS1 is to follow the CS1 guideline regarding displayed order of parameters, type of separators, and text styling. To render input in CS1 (a lesser concern), common parameter names, dependencies between parameters and style-wide required parameters must also conform to CS1. Obviously, any archive-specific parameters are extras. By all means ignore the opening sentence in Help:Citation Style 1; it is self-contradictory, erroneous and badly written.

Citation Style 1 (CS1) is a collection of reference citation templates that can be modified to create different styles for different referenced materials. Its purpose is to provide a set of default formats for references on Wikipedia. It includes a series of templates that in turn use Module:Citation/CS1.

Whatever.

I don't think that the links you posted re:citing archives/manuscripts are pertinent here, except in the most general sense. They are obviously intended for a much more specialized audience. In the same vein, although {{cite archive}} seems like a decent template, it may be too detailed when it comes to the archival service's internal filing particulars. Do we really need to know the accession date of a manuscript in order to provide Wikipedia readers with a way to get at the manuscript and verify the claims of the citing article? I don't know, but my guess is "no". 65.88.88.126 (talk) 13:37, 3 October 2016 (UTC)

I'm not so sure we would be able to come up with a template for archival material, due to the wide variety of types of archives and varied methods of accessing them. For example, a manuscript that has been imaged and then put behind a paywall, so a URL can't be given directly to the page of interest; rather, brief instructions on how to search once inside the paywall would have to be provided. In such a case, if the rest of the article uses CS1 or CS2, I would suggest writing a free form citation in a way that resembles CS1 or CS2 as much as possible, and enclosing it with {{Wikicite}}.

A particular issue with archives, and which I view as a flaw in {{cite archive}}, is that many archive items will not have a title, so the editor writing the citation will have to create a brief description instead of a title. Outside style manuals usually call for such a description to be normal upright text with no enclosing quotation marks. CS1 and CS2 do not provide a mechanism to use descriptions in place of titles. Jc3s5h (talk) 14:49, 3 October 2016 (UTC)

The conversations that led to {{cite archive}} begin here and continue here. That latter place, or the template's talk page are the places to raise concerns with {{cite archive}}, not here.

—Trappist the monk (talk) 15:04, 3 October 2016 (UTC)

Any updates on adding open access links to references?

For simplicity's sake, I suggest we implement the coloured version of the locks, with |access= (paired for whatever link is in |url=) and |id-access= to append locks after the identifiers (replace 'id' with 'bibcode'/'doi'/etc.). We can then refine the behaviour later after we see what issues come up. Headbomb {talk / contribs / physics / books} 14:27, 14 September 2016 (UTC)

I totally agree! I think that's what is currently implemented in the sandbox (but only for id=doi, not for the others). We are ready to submit OAbot to WP:BAG and we can discuss there which icons we want the bot to add (if the current implementation is pushed to live, otherwise there is no discussion to have about that as the bot would not have any option to display the status of the links it adds). − Pintoch (talk) 21:27, 14 September 2016 (UTC)

I also agree that the colored versions are more intuitive and also more consistent with usage outside of Wikimedia. OAbot can do some pretty nifty work, so I think the current implementation is definitely "good enough" to get started with, and as noted above doesn't prevent us from tweaking icons in the future as we progress, get feedback, and learn. Cheers, Jake Ocaasi (WMF) (talk) 22:27, 14 September 2016 (UTC)

Colored versions of the lock are only more intuitive if you as a reader have color sight. For those who don't, the color is more-or-less meaningless; perhaps slightly differing shades of gray. As before, I remain opposed to implementing colored versions of the various locks.

As before, I remain opposed to highlighting the norm. Because named identifiers typically require registration or payment, we should not be adding closed-lock icons to those links. Throughout all of Wikipedia, links in |url= typically link to a readable source; we should not be highlighting those by adding open-lock icons.

I am not opposed to including lock icons in rendered citations where their use is appropriate, distinguishable in color and gray-scale against white or black background, and constrained in their application.

—Trappist the monk (talk) 11:27, 15 September 2016 (UTC)

They are more intuitive, and those with color blindness can still tell them apart by different shapes. Let's implement them, and if we can find a better way of showing this, then we'll refine. We're not saying ignore the 1% here, but to deny the 99% easier access because the information is conveyed in one extra way that the 1% doesn't have access to is silly.Headbomb {talk / contribs / physics / books} 17:36, 15 September 2016 (UTC)

OK. I will not write again here my arguments against your decision to forbid certain locks at certain places as they have not changed either. Are there any chances the change could still be implemented if you acknowledge that there is a consensus for it, or is your own position a definitive veto against it? All I want is to know when to submit the bot for approval: in the first case, we'll try to reach that consensus, in the latter, I'll submit the bot without waiting for CS1 to change. (I am only concerned about which parameters are allowed - the pictures do not have any influence on how the bot should work.) − Pintoch (talk) 17:18, 15 September 2016 (UTC)

Do not put words into my mouth that I have not spoken. I have not ever said that I forbid certain locks, nor have I said that I will veto changes that I do not support. You know that I do not have that power here.

—Trappist the monk (talk) 09:51, 16 September 2016 (UTC)

I can see my comment sounded rude. Please accept my apologies, I am still not familiar with the power structures here (as an admin you do control what gets into the live module, right?). − Pintoch (talk) 10:53, 16 September 2016 (UTC)

No. I do not have that power. Any admin can can be the boatman who conveys changes across the cascading protection (our River Styx). Neither they, nor I control what gets into the live module.

—Trappist the monk (talk) 11:47, 16 September 2016 (UTC)

Trappist's concerns are legitimate and I will comment that he is not the only one who holds them. "A consensus" does not seem to exist with such firmness as you think, and I suspect that an RFC would likely resolve in Trappist's favor on those points. --Izno (talk) 17:28, 15 September 2016 (UTC)

Fine! I thought most editors agreed on the mockup that I followed for my implementation in the sandbox (hence the "consensus"). Trappist was the only one to voice his concerns about this issue after my implementation. Good to see others finally chiming in! I just need the discussion to actually take place, because this detail is holding us back on another front, and I'm happy to see any decision taken about this. I hope this is clearer. − Pintoch (talk) 19:55, 15 September 2016 (UTC)

Let's implement the technicalities, and we'll work out the best practices. I'm not super thrilled about plastering |access=free myself, mostly because the url SHOULD be free by default. If it's not free, then the link adds nothing over |doi=, and should be removed. So the only time you really need to flag anything is if it's not free, and no id/doi are present. Likewise, DOIs should be closed by default, and we flag the free ones (with automated links when that is the case).

So that could mean only allowing |access=subscription/registration/ignoring |access=free and allowing |doi-access=free/ignoring |doi-access=subscription/registration. 17:45, 15 September 2016 (UTC)

They appear to have been refuted; and accessibility guidelines (our own, and the W3C's) suggest not relying on colour alone to distinguish items; they do not deprecate its use at all. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:20, 15 September 2016 (UTC)

I join others above in expressing doubts that there is sufficient consensus for the proposals as they stand. Both the icons to be used and the circumstances of their use have been debated and changed back and forth several times. There should be a clear proposal, or a clear small set of alternative proposals, and then a much wider RfC. Nothing less will be satisfactory for a change with such a significant visual impact all over Wikipedia. Peter coxhead (talk) 19:43, 15 September 2016 (UTC)

Let me join in the chorus of people here who are skeptical about this proposal. It cluttters up the citations, is not always easy to define (is a site that limits you to a certain number of downloads per month open access? is a link that works when you follow it from a specific other link, but not when you copy and paste the same url into Wikipedia, open access?), is about a specific link rather than the whole citation but is proposed to be parameterized and displayed in a way that does not indicate which links are open and which are not (the same paper can be open access through one access method and not open access through another), and is of dubious value to most readers. We can continue to discuss it and mock things up, of course, but I remain unpersuaded. Just because we can do something doesn't mean we should. —David Eppstein (talk) 20:03, 15 September 2016 (UTC)

The locks would apply to the links provided. doi:10.1234/whatever may sometimes resolve to different places, but never one that's open access and another that isn't. The lock on that doi would reflect the state of that link. We might need some more discussion, but right now what I'm proposing, and that I think is likely to be agreed on, is that |url= link shows when they ARENT free, while identifier links shows when they ARE free. But let's at least have a working sandbox version so we can debate and tweak behaviour as needed. And then we can RfC for deployment or something.Headbomb {talk / contribs / physics / books} 20:22, 15 September 2016 (UTC)

Re the different potential expansions of a doi never having different open-access statuses: [citation needed]. And what do you propose to do with links like the ones generated by {{MR}} that already give you useful information when accessed openly but give enhanced information to subscribers? —David Eppstein (talk) 22:15, 15 September 2016 (UTC)

Re doi: You can't prove a negative, and you know that. But I do citation cleanup like few people do, and I have never once ran into a doi that resolves to both an open and a closed access provider. That's because articles are either openly licensed, in which case they will be openly licensed to both providers, or they aren't, in which case neither providers will provide it.

Re MR: MR is closed/subscription based, and non-subscribers do not have access to the review. The options available are, mark it locked (which I think is unecessary/overkill, but others might differ), or do like we do now (which I think is the best behaviour, but again others might differ) and leave the MR link plain.

Re clutter: The locks are certainly better than Smith, J. (2016). "Article of things". Journal of Things. 1 (2): 3. doi:10.1234/whatever. {{cite journal}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help) as far as reducing clutter go (and have the added benefit of applying to the link, rather than to the citation).Headbomb {talk / contribs / physics / books} 22:48, 15 September 2016 (UTC)

I have to go along with Headbomb, that we need a fully functional sandbox version so that we can compare the output with the existing templates to see what works best. Keith D (talk) 23:04, 15 September 2016 (UTC)

I have changed the sandbox to forbid |access=free and |doi-access=subscription. Intermediate access levels are currently allowed on both |access= and |doi-access= (but it's straightforward to change). |id-access= is not implemented for other ids. I can add them if you think that it would ease the discussion (but as far as I can tell they would work just like |doi-access=, right?). So I believe the sandbox is functional now. − Pintoch (talk) 06:15, 16 September 2016 (UTC)

The identifiers that need to be flagged would behave like that, yes. However, some are always free (arxiv, biorxiv [see above discussion], rfc, pmc, and possibly others) while others are always closed (mr, possibly others) and for others it's just irrelevant (asin, lccn, issn, isbn, oclc, ol) so we don't need to have an |arxiv-access=/|mr-access=/|asin-access= parameters. Only those that vary would need to have an access-parameter. Of the identifiers we support, I'm not sure of jstor, jfm, osti, ssrn, zbl as well as the proposed citeseerx support. I know bibcode/doi vary, I think citeseerx/jstor vary as well, but that jfm/zbl are always non-free and osti/ssrn are always free. But that's something that needs to be verified. Headbomb {talk / contribs / physics / books} 12:05, 16 September 2016 (UTC)

Perhaps this has been asked and answered: why do we need |access= when there is already |subscription= and |registration=? Are these not possibly conflicting?

—Trappist the monk (talk) 09:51, 16 September 2016 (UTC)

Those should be deprecated/cleaned up by bots when the new system is rolled out. Headbomb {talk / contribs / physics / books} 12:05, 16 September 2016 (UTC)

In my opinion, the main problem with |subscription= and |registration= is that it is unclear which link they apply to (given how they are currently rendered). Here is an instance where the |url= is closed, but |subscription= adds a note just after the CiteSeerX id, which is open:

Simpson, Alex (2012). "Measure, Randomness and Sublocales". Annals of Pure and Applied Logic. 163 (11): 1642–1659. CiteSeer^x: 10.1.1.220.7880. {{cite journal}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)

It has also been pointed out that |subscription= is quite verbose. However, I agree that allowing both |access= and |subscription= is annoying. I think we should deprecate these old parameters in favor of the new system we are discussing here. It might be possible to migrate existing |subscription= and |registration= to the new system with a bot, but that could only be done in unambiguous cases. − Pintoch (talk) 10:24, 16 September 2016 (UTC)

The conflict I was thinking about was |access=subscription and |registration=yes (and vice versa). I have always taken |subscription= and |registration= to apply to |url= but I can see that the template documentation is not clear on that. If this |access= proposal is adopted, then I agree that |subscription= and |registration= should be deprecated. For the case of a single external link, either by |url= or a named identifier, a bot could replace or remove |subscription= and |registration=.

—Trappist the monk (talk) 11:47, 16 September 2016 (UTC)

Concerning this conflict, should we simply raise an error in the cases you mention? About the ambiguity of |subscription= and |registration=, let me stress that a good documentation would not solve the problem: the rendered output is still ambiguous to readers, because most readers will not read the CS1 documentation. − Pintoch (talk) 13:25, 16 September 2016 (UTC)

Yes. I have done so:

"Title". journal. {{cite journal}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)

"Title". journal. {{cite journal}}: Unknown parameter |registration= ignored (|url-access= suggested) (help)

—Trappist the monk (talk) 10:44, 17 September 2016 (UTC)

Adding different access icons and related links

Is there any reason for adding a non-free source link to a citation when there is a free one? You present a false dilemma. 72.43.99.146 (talk) 12:33, 16 September 2016 (UTC)

This will not usually be done intentionally, but right now (see #automatic url generation below), since free links are not flag/automatically linked, many people add urls even when free sources are available just so there is a link to click. But there's also the case of someone initialy adding |url=http://www.example.com |subscription=yes for something non-free, and then someone / a bot later (like a CiteSeerX bot) adding |citeseerx=123456 |citeseerx-access=free, which would create the above situation. Headbomb {talk / contribs / physics / books} 12:46, 16 September 2016 (UTC)

I would think it should be the bot writer's job to have the bot check whether a source is already verifiable online through the current citation before adding yet another link? I still don't see the logic behind having both free and non-free links. 72.43.99.146 (talk) 13:02, 16 September 2016 (UTC)

What you're proposing that is that bots remove existing urls when they add free links, and that is something very, very risky. While it'll certainly be possible to do so in some case, for most links it will be nearly impossible to confirm whether or not an existing url is freely accessible or not. Headbomb {talk / contribs / physics / books} 13:18, 16 September 2016 (UTC)

In this particular example, the free version is only a preprint that significantly differs from the published version (the URL points to that version). The url is still useful to the happy few who can jump the paywall. In general, there are many reasons why non-free URLs or identifiers are useful even when there is a free one: for instance to generate richer COinS data, or to help readers find the article in their library's database (because they like reading a paper copy, say). − Pintoch (talk) 13:25, 16 September 2016 (UTC)

What is the citation verifying? Is it a claim that is sourced at the preprint or at the peer-reviewed version? Or both? If it is on both, only the free link is required for purposes of verification. If it is in either version, the links would be mutually exclusive. 72.43.99.146 (talk) 13:47, 16 September 2016 (UTC)

The statement is always backed by the official/published version. The preprint is a link of convenience. Headbomb {talk / contribs / physics / books} 14:56, 16 September 2016 (UTC)

Whether a version is official or not is irrelevant. Does it verify the related claim in the text? Then that is the only link (and icon) necessary. It is fine to provide additional information but be mindful of the overhead. 100.33.37.109 (talk) 01:17, 17 September 2016 (UTC)

It matters very much, because if the claim didn't survive peer review, then the source doesn't support the statement it is meant to support the article needs to be revised accordingly. Headbomb {talk / contribs / physics / books} 09:08, 17 September 2016 (UTC)

A single citation cannot point to two different versions/editions/reprints.

If an article, for whatever reason, states something from a particular version, and correctly cites that version, that is all that is needed. The editor can add |edition=preprint or |edition=peer-reviewed.

If it cites something as included in one version but not another, two different citations are needed. The editor can add |edition=preprint and |edition=peer-reviewed.

If the versions are identical, either can be used. Because the point is to verify the text, by whatever means, and there is no issue of reliability here. It is the contributor's choice to include the info about the versions being identical, in article text or non-reference footnote.

If the version cited is the non-free peer-reviewed one, and the particular statement is included in both, and the preprint is free, a |url= free link comparable to the one in {{cite book}} can be used. Such links do not need to be shown as free. Their existence as |url= without an access note in the citation, suffices. Again It is the contributor's choice to include the info about the versions, in article text or non-reference footnote.

The proposed proliferation of icons and parameters unnecessarily complicates this. Imo, per the current policies and citation guidelines, there is no need for the module(s) to accomodate different icons and related links per citation, taking into account the required overhead. 72.43.99.138 (talk) 13:40, 17 September 2016 (UTC)

Simply put, you're wrong because you're conflating several different and unrelated issues. We are not citing two versions, we are citing one version, and providing a convenience link to a preprint which is most of the time accurate as far as the information goes, but lacks the polish and format of a professionally edited final version. This link is useful because preprints are free, while published versions often aren't, and if the publisher's website is down, you can still access the preprint version. If the preprint version is what is cited, then we would use {{cite arxiv}} or similar. Headbomb {talk / contribs / physics / books} 14:17, 17 September 2016 (UTC)

I did not propose that preprint-version links should not be included. The last example in my previous comment states that such links, when they are used in a citation of a non-free, peer-reviewed article, should be treated the same way similar links are treated in {{cite book}}: using the pre-existing |url= without any additional access note, which by default signifies a free link. I completely support adding free links that directly verify the citation; I just don't believe an extra icon and/or access note is required. That is also the case with free doi ids etc.: either format them as |url= instead, or eschew the url link and (if so decided) add a free-access icon to |doi=. 72.43.99.138 (talk) 14:48, 17 September 2016 (UTC)

If your objection is simply the existence and use of icons, then consensus seems to be against you. Headbomb {talk / contribs / physics / books} 20:48, 17 September 2016 (UTC)

It is not just aesthetics. It is also the added complexity and overhead in the code. The added complexity is not static. It may return with a bite any time the code has to be modified, one more thing to take into account. I don't think the payoff is worth it. 72.43.99.138 (talk) 14:28, 18 September 2016 (UTC)

Hum, are we talking here about the complexity of the code required to implement |access=, |doi-access= and the others? If so, have you had a look at the relevant changes in the sandbox? The footprint is actually very small. After a (long) deprecation period for |subscription= and |registration=, we should eventually be able to remove these parameters, which would even simplify the code a bit. I agree we have to be careful to implement it in a responsible way, but I think the current approach is quite modular and fits well with the rest of the code. If you have any specific concern about the way it is currently implemented, let's discuss it. − Pintoch (talk) 15:27, 18 September 2016 (UTC)

Code footprint is not the issue. Complexity is not a result of mass, but of relationships. The effect of which, especially when they cascade (as they will invariably do), can be difficult to gauge beforehand. I am looking at what is being gained by implementing this. To me, the gain seems borderline trivial. This is not a reflection on OAbot per se. I'm not lingering on this because I want to micromanage, delay, or be obstructive. But once something wrong is applied, it takes forever (or never) to make right. The only chance to avoid this usual Wikipedia grind (due to the slowness and fragility of consensus building) is to make sure things are right the first time. Because something obviously true in the real world may not be obvious, nor true, where "Wikipedians" are concerned. 65.88.88.127 (talk) 18:34, 18 September 2016 (UTC)

Can you pinpoint some concrete case where this proposal could interfere with other aspects of CS1? Your point seems to be applicable against any new feature. (Moreover, this is not a new feature: this is a refinement of an existing one.) I don't think the gain is marginal. If we add a |citeseerx= or |hdl= while there is already a |url=, the change will go mostly unnoticed. People don't know if these ids give access to the full text, they will just click on |url=. And again, as in the example above, changing |url= is not an option. Peer reviewing really matters. − Pintoch (talk) 19:51, 18 September 2016 (UTC)

As I mentioned, I cannot know where the new dependencies may bite in the future. I can only do the cost-benefit analysis according to the perceived benefit. Furthermore, my opinion is as non-binding as anyone's. 65.88.88.126 (talk) 15:03, 19 September 2016 (UTC)

CiteSeerX id structure

Copied from an email I got from the CiteSeerX people

Resources ingested by CiteSeerX require a unique ID, or Digital Object Identifier (DOI) that will stay the same for lifespan of the resource. DOIServer provides the means to obtain unique DOIs safely, such that once a particular DOI is issued, that DOI will never be issued again at a particular site or at other sites that use DOIServer. DOIs are of the following form:

<SITE_ID>.<DEPLOYMENT_ID>.<TYPE>.<BIN>.<RECORD>

All variables are integers and have the following semantics:

• SITE_ID: a label that uniquely identifies the site where CiteSeerX is hosted.

• DEPLOYMENT_ID: a label that uniquely identifies the particular DOIServer deployment within the site (allows safe replication of DOIServer application).

• TYPE: a label identifying the type of resource that a DOI was issued for.

• BIN: an ID space for a particular resource type, meant to bound the size of the DOI string.

• RECORD: an ID for a particular resource, with values ranging from 1–9999.

When a new DOI is issued for a particular site, deployment, and resource type, if incrementing the RECORD field would result in a value greater than 9999, the BIN value is incremented instead and the RECORD value is dropped to 1.

This should be useful for error checking. Headbomb {talk / contribs / physics / books} 21:59, 20 September 2016 (UTC)

Can your contact identify what the legitimate value-ranges for these elements are? Besides the record element, which has a defined range of 1–9999, are there similar limits to the range-size of the other elements? Are there illegal values for some or all of these elements? (0 is apparently illegal for the record element).

—Trappist the monk (talk) 10:08, 21 September 2016 (UTC)

I'll ask. Headbomb {talk / contribs / physics / books} 11:45, 21 September 2016 (UTC)

Their answer

"In principle, all fields could range between 1 and 9999. If, let's say, a mirror of CiteSeerX is deployed on another site in the future, the SITE_ID may be different. Currently, the first three numbers are fixed, literally <SITE_ID>=10, DEPLOYMENT_ID=1, TYPE=1. The <BIN> could go from 1 to 9999. Currently this field only has three digits but it is increasing. Let me know if this answers your question."

So it seems that, for now, it's 10.1.1.(1-999).(1-9999). Depending on how stringent we want to be, this could be our error check, and then we'll adapt in the future when we run into issues and update to 10.1.1.(1-9999).(1-9999) or similar. Or we could anticipate the expansion, and implement 10.1.1.(1-9999).(1-9999) right off the bat to not worry about the rollover. Or we could allow the most general case of potentially valid ids with (1-9999).(1-9999).(1-9999).(1-9999).(1-9999) from the outset and never again worry about things, but I feel this would be much less useful. Headbomb {talk / contribs / physics / books} 20:42, 21 September 2016 (UTC)

Current state of the sandbox

Cite journal comparison

Wikitext	{{cite journal|date=2007-09-29|first=Charles S.|issue=1|journal=Origins of Life and Evolution of Biospheres|last=Cockell|pages=87–104|title=The Interplanetary Exchange of Photosynthesis|url-access=subscription|url=http://link.springer.com/article/10.1007/s11084-007-9112-3|volume=38}}
Live	Cockell, Charles S. (2007-09-29). "The Interplanetary Exchange of Photosynthesis". Origins of Life and Evolution of Biospheres. 38 (1): 87–104.
Sandbox	Cockell, Charles S. (2007-09-29). "The Interplanetary Exchange of Photosynthesis". Origins of Life and Evolution of Biospheres. 38 (1): 87–104.

Cite journal comparison

Wikitext	{{cite journal|arxiv=1412.8548|date=2014-12-28|doi-access=free|doi=10.4204/EPTCS.172.23|first1=Krzysztof|first2=Jamie|journal=Electronic Proceedings in Theoretical Computer Science|last1=Bar|last2=Vicary|pages=316–332|title=A 2-Categorical Analysis of Complementary Families, Quantum Key Distribution and the Mean King Problem|volume=172}}
Live	Bar, Krzysztof; Vicary, Jamie (2014-12-28). "A 2-Categorical Analysis of Complementary Families, Quantum Key Distribution and the Mean King Problem". Electronic Proceedings in Theoretical Computer Science. 172: 316–332. arXiv:1412.8548. doi:10.4204/EPTCS.172.23.
Sandbox	Bar, Krzysztof; Vicary, Jamie (2014-12-28). "A 2-Categorical Analysis of Complementary Families, Quantum Key Distribution and the Mean King Problem". Electronic Proceedings in Theoretical Computer Science. 172: 316–332. arXiv:1412.8548. doi:10.4204/EPTCS.172.23.

Cite journal comparison

Wikitext	{{cite journal|date=1992-10-01|doi-access=subscription|doi=10.1139/f92-220|first1=K. K.|first2=R. C.|first3=J. R.|issue=10|journal=Canadian Journal of Fisheries and Aquatic Sciences|last1=English|last2=Bocking|last3=Irvine|pages=1982–1989|title=A Robust Procedure for Estimating Salmon Escapement based on the Area-Under-the-Curve Method|url-access=free|url=https://www.researchgate.net/profile/James_Irvine5/publication/233865122_A_Robust_Procedure_for_Estimating_Salmon_Escapement_based_on_the_Area-Under-the-Curve_Method/links/09e4150c65bae92991000000.pdf|volume=49}}
Live	English, K. K.; Bocking, R. C.; Irvine, J. R. (1992-10-01). "A Robust Procedure for Estimating Salmon Escapement based on the Area-Under-the-Curve Method" (PDF). Canadian Journal of Fisheries and Aquatic Sciences. 49 (10): 1982–1989. doi:10.1139/f92-220. {{cite journal}}: Invalid |doi-access=subscription (help); Invalid |url-access=free (help)
Sandbox	English, K. K.; Bocking, R. C.; Irvine, J. R. (1992-10-01). "A Robust Procedure for Estimating Salmon Escapement based on the Area-Under-the-Curve Method" (PDF). Canadian Journal of Fisheries and Aquatic Sciences. 49 (10): 1982–1989. doi:10.1139/f92-220. {{cite journal}}: Invalid |doi-access=subscription (help); Invalid |url-access=free (help)

− Pintoch (talk) 06:15, 16 September 2016 (UTC)

Personally, if |access/doi-access= are set to any 'valid' access options (free/registration/subscription), I wouldn't output error messages for the options we disallow. Those would act as a sort of edit-window comment of "yeah, I've actually checked this link, and it is freely accessible" / "yeah I've checked this doi, and it isn't freely accessible". Error messages should, IMO, only be displayed if |access/doi-access= is set to something like "24$" or "Smith 2005 et al.". Headbomb {talk / contribs / physics / books} 07:56, 16 September 2016 (UTC)

However, maybe we'll want to give the option of having the locks displayed, and make it a guideline (but not a hard rule) that those are best omitted in the instances where the url is free, and that the doi is not. Headbomb {talk / contribs / physics / books} 08:03, 16 September 2016 (UTC)

I agree with both comments. − Pintoch (talk) 08:12, 16 September 2016 (UTC)

Oppose the latter as highlighting the norm, and the former because excessive use becomes just so much clutter in the wikitext. If there is a need for a note in a reference, such notes can and should be enclosed in <!-- hidden comments -->.

—Trappist the monk (talk) 09:51, 16 September 2016 (UTC)

I fail to see how |url=http://www.example.com<!-- Open access link --> reduces clutter when compared to say, |url=http://www.example.com |access=free. However, I'm not sure exactly to what you are referring to with 'former' and 'later'. Headbomb {talk / contribs / physics / books} 10:38, 16 September 2016 (UTC)

|url=http://www.example.com<!-- Open access link --> and |access=free are just two forms of highlighting-the-norm. My statement was qualified: If there is a need .... The need to highlight the norm should be rare and because of rarity, html comments suffice.

You made two posts: the former and the latter.

—Trappist the monk (talk) 11:23, 16 September 2016 (UTC)

Automatic url generation

In the case of the free doi (and other free ids of official versions), |url= should be automatically populated with "https://dx.doi.org/{{{doi}}}" to match the behaviour of |pmc= which automatically populates |url= with "https://www.ncbi.nlm.nih.gov/pmc/articles/PMC{{{PMC}}}". Then we can see a priority of |url= (manual) > |doi= (automatic link) > |pmc= (automatic link) to prioritize which automatically-generated url gets used (assuming |url= is empty), and also support |url=doi/pmc so we can override the priority of url-generation if needed. Might be best to wait till later to get into this however. Headbomb {talk / contribs / physics / books} 08:23, 16 September 2016 (UTC)

Assuming that |url= is automatically populated, then the id should be unlinked. Having 2 links to the same content in a single citation would be superfluous. 72.43.99.146 (talk) 12:57, 16 September 2016 (UTC)

Doing that would be extremely confusing and contrary to established practice. Headbomb {talk / contribs / physics / books} 13:45, 16 September 2016 (UTC)

Simplicity is confusing? If established practice is wrong, it should go on because it is established, I suppose. 72.43.99.146 (talk) 13:53, 16 September 2016 (UTC)

Having something like

• Bar, Krzysztof; Vicary, Jamie (2014-12-28). "A 2-Categorical Analysis of Complementary Families, Quantum Key Distribution and the Mean King Problem". Electronic Proceedings in Theoretical Computer Science. 172: 316–332. arXiv:1412.8548 . doi:10.4204/EPTCS.172.23 .

Would be very confusing, yes. Headbomb {talk / contribs / physics / books} 14:13, 16 September 2016 (UTC)

I agree that the example above would be confusing. I would counter-propose then that |url= should be not be populated when a content id like |pmc= etc. exists. Obviously this would not apply to non-content ids like |issn= etc. 72.43.99.146 (talk) 14:31, 16 September 2016 (UTC)

Well that's against long-established practice. You're free to try and gain consensus for a different behaviour, but not 'main linking' to a free source is a pretty unlikely to pass proposal. Headbomb {talk / contribs / physics / books} 14:53, 16 September 2016 (UTC)

Re: "long-established practice": Time rights wrongs? 72.43.99.138 (talk) 13:45, 17 September 2016 (UTC)

That would be very nice indeed! But we should make sure the logic remains simple. − Pintoch (talk) 13:53, 16 September 2016 (UTC)

The logic should be fairly simple, at least as far as template users are concerned. If there's a free link (|pmc=something or |doi-access=free is specified, the template automatically makes a link. The details of what is linked when multiple free links are available would be taken care of by the template, and in most situations no one needs to do anything else except to flag the 'freeness' of the doi with |doi-access=free. But the option to override the template's preference for a certain identifier for the main link would be there if it makes sense for that article (e.g. on medical articles, it may be that a link through pmc is preferable to a link through doi, in which case, you could just add |url=pmc or something to that nature). Headbomb {talk / contribs / physics / books} 14:20, 16 September 2016 (UTC)

Astonishing. For once, the IP editor and I are in agreement. I caught hell from editors at WP:MED when I removed the automatic title linking when |pmc= is set. I thought then that such linking was redundant and now that the PMC link is marked with a free-to-read icon, think that such auto-linking is doubly redundant.

I don't think that we should overload parameters. If an editor wants to override the current PMC auto-linking of |title=, they provide a url in |url=. Doing it that way relieves the template of the need to prioritize one free-to-read named identifier over another. I don't think that the templates should be in the prioritizing business.

—Trappist the monk (talk) 11:28, 18 September 2016 (UTC)

Except this creates issues in print, because you'd have something like Bar, Krzysztof; Vicary, Jamie (2014-12-28). "A 2-Categorical Analysis of Complementary Families, Quantum Key Distribution and the Mean King Problem". (https://dx.doi.org/10.4204%2FEPTCS.172.23) Electronic Proceedings in Theoretical Computer Science. 172: 316–332. arXiv:1412.8548 . doi:10.4204/EPTCS.172.23 . showing up. Autolinking solves that and reduces edit window clutter from unnecessary urls and accessdates. Headbomb {talk / contribs / physics / books} 12:18, 18 September 2016 (UTC)

I would also oppose automatic filling of |url=, because it is redundant, adds needless complication, and clashes with the possibility of wikilinking a notable work. Kanguole 09:41, 4 October 2016 (UTC)

It's already done for other free identifiers (PMC), as far as wikilinking goes, automatic linking can be coded in a way that avoids that issue. Because right now, LOTS of people put both |url=http://dx.doi.org/10.1234/0123456 and |doi=10.1234/0123456 or both |url=http://adsabs.harvard.edu/abs/1924MNRAS..84..308E and |bibcode=1924MNRAS..84..308E when sources are free. This adds significant clutter both in the edit window, but especially when you print articles (see above example). Headbomb {talk / contribs / physics / books} 11:17, 4 October 2016 (UTC)

I think the treatment of PMC is a mistake that we oughtn't to spread (for the above reasons), and I remove redundant settings of |url= to the same target as a linked identifier when I come across them. Kanguole 13:10, 4 October 2016 (UTC)

Which identifiers?

Identifier	Full text access?	Template	Examples	Decision
|arxiv=	Always	{{arxiv}}	arXiv:1412.8548	Always append
|biorxiv= (?)	Always	{{biorxiv}}	bioRxiv 047720	Always append
|citeseerx= (?)	Always	{{citeseerx}}	CiteSeerx: 10.1.1.220.7880	Always append
|pmc=	Always	{{PMC}}	PMC 50050	Always append
|rfc=	Always	{{IETF-RFC}}	RFC 125	Always append
|ssrn=	Always	{{SSRN}}	SSRN 871210	Always append
|bibcode=	Sometimes	{{bibcode}}	Bibcode:1974AJ.....79..819H is , Bibcode:1998ApJ...508L..81K is not	Use |bibcode-access=free
|doi=	Sometimes	{{doi }}	doi:10.4204/EPTCS.172.23 is , doi:10.1139/f92-220 is not	Use |doi-access=free
|hdl=	Sometimes	{{hdl}}	hdl:1808/3638 is , hdl:1893/23021 is not	Use |hdl-access=free
|jstor=	Sometimes	{{JSTOR}}	JSTOR 10.1086/673276 is , JSTOR 123456 is not	Use |jstor-access=free
|ol=	Sometimes	{{OL}}	OL 25894862M is , OL 5665961M is not	Use |ol-access=free
|osti=	Sometimes	{{OSTI}}	OSTI 4435330 is , OSTI 4045588 is not	Use |osti-access=free
|asin=	No	{{ASIN}}	ASIN B00086U61Y	No icon
|isbn=	No	{{ISBN}}	ISBN 0-7475-3269-9	No icon
|ismn=	No	{{ISMN}}	ISMN 979-0-2600-0043-8	No icon
|issn=	No	{{ISSN}}	ISSN 0028-0836	No icon
|jfm=	No	{{JFM}}	JFM 54.0271.04	No icon
|lccn=	No	{{LCCN}}	LCCN 89-456	No icon
|mr=	No	{{MR}}	MR0123456	No icon
|oclc=	No	{{OCLC}}	OCLC 632791477	No icon
|pmid=	No*	{{PMID}}	PMID 123456	No icon
|zbl=	No	{{zbl}}	Zbl 06626752	No icon
* If it's free, it will have both a PMID and PMC. PMID technically provides a link to a freely-accessible version, but it's the PMC version. So for purpose of displaying the free icon, it should be on the PMC, and not on the PMID, since the PMID link would point to the PMC version anyway.

I propose we build a table summarizing the status of all identifiers currently supported by CS1 with regard to these free to read icons. Feel free to edit it directly. − Pintoch (talk) 14:22, 20 September 2016 (UTC)

@Headbomb:, I am not familiar with bibcode: does this service store any full text? It seems to me that they redirect to the publisher's version or arXiv (which should be already covered by |doi= and |arxiv=), at least in the example you give. It looks similar to |pmid= in this respect, so I am not sure an icon is useful there? − Pintoch (talk) 17:59, 20 September 2016 (UTC)

The ADSABS database (which is what the bibcode links to) does offer free full versions of many articles, although not articles with a bibcode will have a free full article. I'm not home (I'm at work, where I have access to some sources via our academic subscription), but I will be there soon. I'll find an example where there is a free version available to the public in the next hour or so, and I'll update the box accordingly. Headbomb {talk / contribs / physics / books} 18:31, 20 September 2016 (UTC)

Thanks for the examples (and other improvements to the table), it does make sense to add an icon indeed. − Pintoch (talk) 07:49, 21 September 2016 (UTC)

Somewhat relatedly, the doai project seems to be a somewhat official way of finding open-access versions of papers from their closed-access doi. For instance the doai version of the non-free doi example above links to a free pdf on the same paper, apparently in this case made available through ResearchGate. —David Eppstein (talk) 23:27, 20 September 2016 (UTC)

Yes, this is one of the sources OAbot will be pulling from. − Pintoch (talk) 07:49, 21 September 2016 (UTC)

PMC error checking adjustment

QuackGuru has edited the Help:CS1 errors page to note that |pmc= values higher than 5000000 are being issued by PubMed. See, for example:

S. Klotz; et al. (26 Aug 2016). "Ice VII from aqueous salt solutions: From a glass to a crystal with broken H-bonds". Sci Rep. 6: 32040. doi:10.1038/srep32040. PMC 5000010.

The above message generates an error message at this writing, because our error check for |pmc= looks for PMC IDs between 1 and 5000000 (five million). I have adjusted the sandbox code to allow for values up to 6000000 (six million):

Questions or comments are welcome. – Jonesey95 (talk) 00:01, 16 September 2016 (UTC)

This doesn't need debate, just fix it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:46, 16 September 2016 (UTC)

Unless I made a coding error, it is fixed and will be put into production at the next module update. The last module update was on 30 July 2016. We have done about eight updates per year for the last two years. – Jonesey95 (talk) 13:51, 16 September 2016 (UTC)

This is a bug fix, not a feature improvement, and therefore should be expedited. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:39, 16 September 2016 (UTC)

If you can convince a template editor/admin to make the change (hint: you shouldn't be able to based solely on Jonesey's comment, and I wouldn't implement it either), then sure, it should be expedited. But any template editor worth his salt is going to check for consensus first for this module and that you will not find. Wait, just like everyone else ever has. --Izno (talk) 15:18, 16 September 2016 (UTC)

You think there's no consensus to fix an obvious and demonstrated error? I'd have done it myself already, were the module not fully protected. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:03, 16 September 2016 (UTC)

No, I think there's no consensus to fix an obvious and demonstrated error in this module. It's a subtle but distinct point. --Izno (talk) 16:07, 16 September 2016 (UTC)

Is this upper bound on the PMC identifier really worth all this trouble? Four editors have been involved in fixing it already! If such a constant needs to be updated manually that often (and generate meta discussions at the same time), it should not be treated as a constant. I would either remove the check or put a really high value like 10-15 million. I believe such a tight check brings more hassle to template maintainers than it helps editors spot wrong PMC IDs. − Pintoch (talk) 17:37, 16 September 2016 (UTC)

The check was implemented in this change from March 2014 based on Module talk:Citation/CS1/Archive 9#PMC error check needed. About 2.5 years ago, the need was for 4 million (and only 5 million due to need for space). A maintenance-free implementation might increment the return value at 1 million/2.5 years ~= an increase of 1100 per day. Otherwise, we should just leave ourselves a note to check every 2 years or so to further increment the value. --Izno (talk) 18:19, 16 September 2016 (UTC)

I think it may be valuable to keep in mind that there are currently zero articles in ‹The template Category link is being considered for merging.› Category:CS1 errors: PMC. This means that there are no articles citing PMC IDs over 5000000 at this time. We do not typically expedite bug fixes to this widely used template unless they are causing havoc in article space. – Jonesey95 (talk) 04:13, 17 September 2016 (UTC)

Update: As of this writing, there are four article with PMC values over 5000000. All are showing red error messages. I know we are still making changes to the sandbox, but it may be time to put at least some of those changes into production. – Jonesey95 (talk) 17:06, 28 September 2016 (UTC)

Without seeing this discussion, I bumped the limit to 5100000 as a stopgap. That'll prevent false positives for a while, and hopefully the sandbox changes can make it out in time. {{Nihiltres |talk |edits}} 14:20, 30 September 2016 (UTC)

id-access support

Per #Which identifiers, we should support

• |bibcode-access=free
• |doi-access=free
• |hdl-access=free
• |jstor-access=free
• |ol-access=free
• |osti-access=free

To make them display green open access locks at the end of their identifier. We should also update

• {{bibcode}}
• {{doi}}
• {{hdl}}
• {{JSTOR}}
• {{OL}}
• {{OSTI}}

to also support the same |foobar-access=yes and have the green open access locks.

And then we should update

• {{arxiv}}
• {{biorxiv}}
• {{CiteSeerX}}
• {{IETF-RFC}}
• {{PMC}}
• {{SSRN}}

to always display the green free access locks. Headbomb {talk / contribs / physics / books} 14:50, 23 September 2016 (UTC)

After a lot of fiddling, the prototype in the sandbox should be mostly functional.

always free

• Doe, J. "Title". arXiv:1001.1234. {{cite journal}}: Cite journal requires |journal= (help)
• Doe, J. "Title". bioRxiv 047720. {{cite journal}}: Check |biorxiv= value (help); Cite journal requires |journal= (help)
• Doe, J. "Title". CiteSeerX 10.1.1.220.7880. {{cite journal}}: Cite journal requires |journal= (help)
• Doe, J. "Title". PMC 50050. {{cite journal}}: Cite journal requires |journal= (help)
• Doe, J. "Title". RFC 125. {{cite journal}}: Cite journal requires |journal= (help)
• Doe, J. "Title". SSRN 871210. {{cite journal}}: Cite journal requires |journal= (help)

id-access

• Doe, J. "Title". Bibcode:1974AJ.....79..819H. {{cite journal}}: Cite journal requires |journal= (help)
• Doe, J. "Title". Bibcode:1998ApJ...508L..81K. {{cite journal}}: Cite journal requires |journal= (help)
• Doe, J. "Title". doi:10.4204/EPTCS.172.23. {{cite journal}}: Cite journal requires |journal= (help)
• Doe, J. "Title". doi:10.1139/f92-220. {{cite journal}}: Cite journal requires |journal= (help)
• Doe, J. "Title". hdl:1808/3638. {{cite journal}}: Cite journal requires |journal= (help)
• Doe, J. "Title". hdl:1893/23021. {{cite journal}}: Cite journal requires |journal= (help)
• Doe, J. "Title". JSTOR 10.1086/673276. {{cite journal}}: Cite journal requires |journal= (help)
• Doe, J. "Title". JSTOR 123456. {{cite journal}}: Cite journal requires |journal= (help)
• Doe, J. "Title". OL 25894862M. {{cite journal}}: Cite journal requires |journal= (help)
• Doe, J. "Title". OL 5665961M. {{cite journal}}: Cite journal requires |journal= (help)
• Doe, J. "Title". OSTI 435330. {{cite journal}}: Cite journal requires |journal= (help)
• Doe, J. "Title". OSTI 4045588. {{cite journal}}: Cite journal requires |journal= (help)

And so on. Note that currently |id-access=registration and |id-access=limited are allowed, although that makes little sense given the identifiers that currently use the system. Should we only allow |id-access=free? − Pintoch (talk) 13:02, 24 September 2016 (UTC)

It might make sense to support |id-acccess=registration/limited, but if we do that, only for doi and (possibly) jstor. However, I don't see anyone, even bots actually bothering to flag those, so I'd personally be in favour of only supporting 'free' per the WP:KISS principle, but it's not a strongly-held opinion. Headbomb {talk / contribs / physics / books} 13:24, 24 September 2016 (UTC)

I agree we should only support |id-access=free ([the documentation was updated to reflect that.) I have therefore [https://en.wikipedia.org/w/index.php?title=Module:Citation/CS1/Configuration/sandbox&diff=744752636&oldid=744680128 updated the code to reflect that. − Pintoch (talk) 06:24, 17 October 2016 (UTC)

Free locks vs url locks

Currently, the free green locks uses Trappist's version of the lock + hover message, while the newer url-access locks use my versions of the locks + hover messages. Those should be made consistent. Headbomb {talk / contribs / physics / books} 10:03, 27 September 2016 (UTC)

More importantly, we should settle the color vs. shape vs. accessibility issue. Having attended to that, we can create a uniformly consistent set of lock images to suit.

—Trappist the monk (talk) 12:42, 27 September 2016 (UTC)

We should, yes, but we should also have consistency in the initial rollout. Headbomb {talk / contribs / physics / books} 13:23, 27 September 2016 (UTC)

I'm quite happy with the current mix, the locks seem consistent to me. As far as I can tell, the only discrepancy is in the alt text: should it be short, like "free to read", or longer, like "A (paid) subscription is required to access this source"? I don't know what is best in terms of accessibility. Concerning shape and color, I think we all agree that one should be able to tell the locks apart from their shapes only. This is currently the case. Then, do we agree that it does not hurt to use different colors, as long as they are not crucial to understand what the locks mean? − Pintoch (talk) 05:43, 29 September 2016 (UTC)

My series of files is File:Lock-green.svg/File:Lock-yellow.svg/File:Lock-red.svg. File:Lock-green.svg differs ever so slightly from File:Free-to-read lock 75.svg in its shade of green (I used the same shade of green/yellow/red), but it also makes better use of its space, and matches the design of the yellow and red locks. Compare

Headbomb {talk / contribs / physics / books} 07:23, 29 September 2016 (UTC)

Here is an attempt to compare color contrast against two backgrounds. The values in the table are taken from this website. I included the en.wiki redlink color as a point of reference. Where the color contrasts aren't balanced, the table suggests alternate rgb values.

color contrasts

lock	color	background white	background black
	#008400	4.9	4.3
	#007a00	5.5	3.8
	#7a7a00	4.6	4.6
	#7a0000	11.5	1.8
	#0077cc	4.7	4.5
redlink	#ba0000	6.8	3.1
alternate colors
	#008900	4.6	4.6
	#ec0000	4.6	4.6
	#0077d6	4.6	4.6

—Trappist the monk (talk) 10:16, 29 September 2016 (UTC)

It should be simple manner to update green to 008900 and red to ec0000. I'll do that right away. Headbomb {talk / contribs / physics / books} 10:30, 29 September 2016 (UTC)

color contrasts

lock	color	background white	background black
	#0077cc	4.7	4.5
	#008400	4.9	4.3
	#008900	4.6	4.6
	#7a7a00	4.6	4.6
	#ec0000	4.6	4.6

Done. Headbomb {talk / contribs / physics / books} 10:40, 29 September 2016 (UTC)

I've implemented this in the sandbox too. I've also tweaked the hover messages to be short and sweet, as well as vertically-aligned the locks so the bottom lines up with the bottom of the letter o. See "Title". {{cite journal}}: Cite journal requires |journal= (help)/"Title". {{cite journal}}: Cite journal requires |journal= (help)/"Title". arXiv:1001.1234. {{cite journal}}: Cite journal requires |journal= (help) Headbomb {talk / contribs / physics / books} 01:54, 30 September 2016 (UTC)

Nice! Although now, to be honest, I find the locks a bit too high - maybe scaling them down while keeping the baseline at the same place would help? But it's a matter of taste. − Pintoch (talk) 06:23, 30 September 2016 (UTC)

They're about as scaled down as they can be at their current size. However, we could shorten the locks' shackle, so that the overall image spans less height. Headbomb {talk / contribs / physics / books} 09:30, 30 September 2016 (UTC)

Or we could leave them like they are now. I was worried they would increase line size, but they don't seem to. Headbomb {talk / contribs / physics / books} 09:34, 30 September 2016 (UTC)

Restore the previous lock positioning. The new position is too high. At their highest points, the lock should be no higher than the height of the tallest character and should be no lower than lowest descender. The characters in the standard font that are both tallest and have the lowest descender are the [] characters, commonly part of arXiv identifier renderings:

Leinster, Tom (2007). "The Euler characteristic of a category as the sum of a divergent series". arXiv:0707.0835 [math.CT]. – live

Leinster, Tom (2007). "The Euler characteristic of a category as the sum of a divergent series". arXiv:0707.0835 [math.CT]. – sandbox.

—Trappist the monk (talk) 10:18, 30 September 2016 (UTC)

With my browser (with the standard font, I suppose), the live version is too low (it goes below []) and the sandbox is too high (it goes above []). − Pintoch (talk) 10:43, 30 September 2016 (UTC)

Play with your appearance settings. For me:

Cologne blue renders the baseline of the live lock at about the baseline of the font; the baseline of the sandbox lock is at about mid-height of a digit character so the top of the lock impinges on the line above it (the two locks in my previous example touch)

Modern is similar to Cologne blue except that the sandbox lock is slightly lower so that the two locks above do not touch

Monobook has the baselines lower. The live lock looks to be just a hair lower than the descender of the adjacent [ character; the baseline of the sandbox lock appears to be just a hair lower than the baseline of the font

Vector puts the baseline of the live lock at or maybe just a hair above the descender of the adjacent [; sandbox lock baseline appears at or slightly higher than the font baseline.

These would suggest that we should not be adjusting the vertical position of the locks.

—Trappist the monk (talk) 12:16, 30 September 2016 (UTC)

Hmmm... that is mighty annoying. I'm using monobook, which explains why they're so misaligned. I wonder if we can't tweak the skins themselves. I suppose it's good enough for now. Very much looking forward to things being rolled out. Trappist the monk, when could we expect this? Over the weekend? Headbomb {talk / contribs / physics / books} 12:23, 30 September 2016 (UTC)

Because of the alignment issue in the various skins, I've reverted that change.

In my mind the remaining accessibility issue is lock shape. The current locks are all the same shape except in the shackle which I think sufficiently vague and why the blue locks that I proposed used the lock-body to differentiate their individual meanings:

Ignoring color, and considering the locks as they might appear in gray-scale, there is little to distinguish the yellow from the red at the size that they will be used.

Changes to the live module are not generally made at a moment's notice. I publish a list of the changes to be made about a week ahead of the planned event so that editors have the chance to have a final say beforehand.

—Trappist the monk (talk) 11:05, 1 October 2016 (UTC)

The problem I have with the alternate set of locks, is that their shapes, while more visually different, are quite unclear.

Free vs Subscription I would say are about as equally clear in both sets of locks, although I don't like that the blue limited/subscription locks loses the middle circle [probably fixable by removing the middle blue dot in the free lock so they are consistent]. The issue really is the limited access lock. While the current version of the yellow lock might not be visually super distinct, it is clear in meaning (i.e. dashed shackle = not a hard lock). I think that issue is fixable by adjusting the shackle's dash density / tweak the shackle's appearance. The blue limited access lock has the opposite issue: it is visually quite distinct, but its meaning completely unclear, especially if it's not wedged between the other two locks. How is a fully closed lock with a half-filled body convey "This source is free to read under certain conditions"? It doesn't, and that is a much deeper issue because the icon itself doesn't make sense. Headbomb {talk / contribs / physics / books} 13:19, 1 October 2016 (UTC)

There, I've tweaked the dash density, and the yellow lock is now much more visually distinct from the red lock. Headbomb {talk / contribs / physics / books} 15:29, 1 October 2016 (UTC)

You are attempting to use fine detail to make the distinction but that fine detail is lost at 9px width (the size that is used in rendered citations). Essentially what you've created is a halftone shackle that appears closed at 9px. My original lock was based on the orange open-access lock (). My version opened the shackle farther because editors noted that they couldn't easily distinguish between open and closed. That's why I chose lock-body-fill as the way to differentiate among the three. In gray scale, and at 9px width, the halftone shackle is slightly fainter than the lock's body; both of which are slightly fainter than a subscription lock. At a comfortable reading distance, the gray-scale subscription and registration locks are distinguishable by shade but not by shape. It is not obvious that the two have different meanings.

Icons can't always communicate exact meaning given the constraints of a size that obscures detail. That's why we have tool tips and alt text so that readers learn what the icon means. Were I new to these icons, the halftone shackle and the half filled lock body would be equally incomprehensible. Is it even possible to fit the exact meaning of 'Free access subject to limited trial, subscription normally required' into 9px? I think not.

—Trappist the monk (talk) 18:29, 1 October 2016 (UTC)

Actually, I've just had an idea for improved locks, and I think this one will satisfy everyone! I have to go to work soon, but I'll upload it later this afternoon, or tonight when I'm back from work. Headbomb {talk / contribs / physics / books} 11:22, 3 October 2016 (UTC)

Lock design

Zoomed in

(current/original)

(alt design 1)

(alt design 2)

(alt design 3)

(alt design 4)

(alt design 5)

(alt design 6)

(alt design 7)

(alt design 8)

(alt design 9)

(alt design 10)

(alt design 11)

Intended size (with tooltips)

"Title" / "Title" / "Title" / "Title" (current/original)

"Title" / "Title" / "Title" / "Title" (alt design 1)

"Title" / "Title" / "Title" / "Title" (alt design 2)

"Title" / "Title" / "Title" / "Title" (alt design 3)

"Title" / "Title" / "Title" / "Title" (alt design 4)

"Title" / "Title" / "Title" / "Title" (alt design 5)

"Title" / "Title" / "Title" / "Title" (alt design 6)

"Title" / "Title" / "Title" / "Title" (alt design 7)

"Title" / "Title" / "Title" / "Title" (alt design 8)

"Title" / "Title" / "Title" / "Title" (alt design 9)

"Title" / "Title" / "Title" / "Title" (alt design 10)

"Title" / "Title" / "Title" / "Title" (alt design 11)

There. I think we have a winner with alt 1 (or alt 3, no strong preference here) alt 4 (or 5, which I have a slight preference for). Colours are there, each with a contrast of 4.6:1 against both black and white backgrounds. The shackles convey the openness, but if you can't make out the details of the shackle or the colour of the lock, the amount of filling in the lock's body also conveys the openness of the link. I believe everyone wins. Headbomb {talk / contribs / physics / books} 15:12, 3 October 2016 (UTC)

Pinging @Trappist the monk, Pintoch, Jonesey95, Ocaasi, Ocaasi (WMF), Izno, Pigsonthewing, David Eppstein, Matthiaspaul, Andrew Gray, Nihonjoe, Mandruss, Obsuser, Tom.Reding, Kanguole, and Martin of Sheffield: for their feedback on the three proposed design. Headbomb {talk / contribs / physics / books} 15:26, 3 October 2016 (UTC)

Off topic discussion about pings and edits

@Headbomb: This edit won't have notified anybody, least of all Andrew Gray. --Redrose64 (talk) 19:30, 3 October 2016 (UTC)

I believe pings are sent when signatures/timestamps are converted from ~~~~~ to 19:35, 3 October 2016 (UTC). If so, then they have been notified. Headbomb {talk / contribs / physics / books} 19:35, 3 October 2016 (UTC)

No. You need to make a new post, including a link to the notifyee(s) and your signature, and it all needs to be done in the same edit, see WP:Echo#Triggering events. Editing an existing post simply won't work; in this edit, all that you did was alter three characters. You might have deleted the existing timestamp and used five tildes before saving, but as far as the notifications system is concerned, it's not a new timestamp, let alone a new post. @Headbomb: I shall demonstrate with my next edit. --Redrose64 (talk) 19:57, 3 October 2016 (UTC)

This is clearly off-topic, but I was notified. This appeared in my notifications seven hours ago: "‪Headbomb‬ mentioned you on ‪Help talk:Citation Style 1‬ in "‪Lock design‬". Pinging @Trappist the monk, Pintoch, Jonesey95, Ocaasi, Ocaasi (WMF), Izno, Pigsonthewing, David Eppstein, Matthiaspaul, Andrew Grey, Nihonjoe, Man..." – Jonesey95 (talk) 22:43, 3 October 2016 (UTC)

@Jonesey95: Yes, you were notified, but by the original post, not by the amendment. --Redrose64 (talk) 22:53, 3 October 2016 (UTC)

(EC) You were in the original post, this is just about Andrew Grey's notification. Anyway, not important, so I'm collapsing this section. Headbomb {talk / contribs / physics / books} 22:57, 3 October 2016 (UTC)

Of the three, alt2 seems to have the most easily distinguished icons. Why not use those icons, but with the green/blue/ red colours? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:34, 3 October 2016 (UTC)

Alt design 1.

[e] @Headbomb: It is better than current/original if we consider colors too (if free registration required and paid subscription required are compared, and user has no color on the screen + screen is small — bigger the chance is he/she will see difference between two mentioned locks in alt design 1 because circle is fully filled in the latter and broken line in the former might appear as non-broken line).

@Pigsonthewing: I think more distinguished icons are in alt design 1a than in alt design 2; empty and full circle have more meaning than dot, half circle and full circle too. --Obsuser (talk) 15:28, 3 October 2016 (UTC)

Perhaps empty, half circle, and full would be better? I've added that row above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:50, 3 October 2016 (UTC)

Tweaked with proper color (alt 3). Headbomb {talk / contribs / physics / books} 15:59, 3 October 2016 (UTC)

Alt 3 is now not what I was proposing. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:14, 4 October 2016 (UTC)

So you wanted specifically green/blue/red as a color scheme??? Well picture me puzzled and categorically opposed to that! Headbomb {talk / contribs / physics / books} 15:17, 4 October 2016 (UTC)

alt design 1, since there are 3 changes per progression (Δshackle, Δbody, Δcolor), making it superior to the others. alt design 2's intermediate design is hard to see. My eye strains when looking at it, like it's looking for more detail in the image, even though I already know how it looks like. I can glance over the others without experiencing that effect. A 40/60-ish blue/not-blue body-fill-in-ratio might be a little better, but still not as good as alt design 1 (probably on par with/slightly better than current/original).

The changes per progression (unlocked→intermediate & intermediate→locked) for each design are:

• current/original: 2 & 2
• alt design 1: 3 & 3
• alt design 2: 2 & 1
• alt design 3: 3 & 3

On this basis I order my preference from most to least favorable as: alt design 1, alt design 3, current/original, alt design 2.   ~ Tom.Reding (talk ⋅dgaf)  16:01, 3 October 2016 (UTC)

I've added a 4th and 5th design, which I think are the best. It still has a partial yellow shackle, but it looks much much better in print. The 5th design keeps the dot in the green lock, which prevents it from looking too much like a lowercase a. Headbomb {talk / contribs / physics / books} 16:59, 3 October 2016 (UTC)

I prefer alt 1 and alt 2 as they are easiest to distinguish as they use both color and fill to indicate the differences. This is important for those who may be colorblind (I am not). ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 18:25, 3 October 2016 (UTC)

I prefer alt 5, but I am happy with any other design. I think it is useful to have the dot inside the green lock, so that it is easier to recognize the similarity with the orange open access lock. Thanks for these proposals! − Pintoch (talk) 22:28, 3 October 2016 (UTC)

Of course I prefer alt2. The suggestion of alt2 in green→blue→red with the same shapes is acceptable. In that vein, alt5 shapes in green→blue→red would also be acceptable. The reasons for this color preference is that the 'yellow' is not yellow but a rather bilious color that reminds me of the content of a baby's diaper.

It occurs to me to wonder if the limited and registration locks should be different. Perhaps the registration lock has its dark half on the left as an indicator that the source goes from closed to open. The limited lock then has its darkened half on the right indicating that the source goes from open to closed. If the alt5 'yellow' lock is chosen, perhaps a 180° flip around the y-axis to put the broken portion of the shackle on the right would be best if this suggestion is adopted. The single break in the 'yellow' lock's shackle is substantially better than the halftone shackle.

—Trappist the monk (talk) 10:20, 5 October 2016 (UTC)

I think that's a subtlety that would be lost on most of us, let alone the average reader. I think yellow/partial shackle conveys 'restrictions' well enough, and that's really all they should convey. I think the KISS principle applies here, and we'd be overengineering if we tried to include finer meanings in the icons. I think the only people who need the distinction are the visually impaired, and the tooltips will cover that (I believe they are read by text-to-speech software. If they aren't, then we'll make use of |alt= in [[File:Lock-green.svg|9px|alt=Freely accessible]]. Headbomb {talk / contribs / physics / books} 17:10, 5 October 2016 (UTC)

I suspect these intermediate access levels will not be used much anyway. It is good to offer them, with different values, but I agree with Headbomb that it seems hard to convey the difference between the two in a tiny icon like that. I think each lock should be in a uniform color for simplicity. − Pintoch (talk) 17:47, 5 October 2016 (UTC)

Of course it is hard to convey complex ideas with simple icons. That is a point I made some time ago and why we have tool tips and alt text. Using a single simple lock icon to communicate two distinctly different but vaguely similar meanings just complicates the matter. That is why I suggested slightly different icons for slightly different meanings. I can agree that the 180° flip around the y-axis of my earlier suggestion is insufficiently distinct. Perhaps a rotation of the lock body by 90° is better:

And, for those seeking meaning in the imagery, one might construe the new lock's bottom-fill as a vague representation of the sand in an hourglass.

—Trappist the monk (talk) 13:23, 8 October 2016 (UTC)

• Interesting - I hadn't realised the discussion had progressed to suggest four options not simply open/shut. Really glad to see someone's working on this! From that perspective, alt2, alt6, and alt7 (half-circle with unbroken top section) look fine when seen as part of a set, but will probably be too confusing in practice - if you don't have a 'full lock' to compare them to, they'll look like closed padlocks and will be assumed to indicate "closed" rather than "half-closed". Which is not a bad fallback, I suppose. Likewise, the part-dashed (alt4, alt5) seem too visually close to the closed upper section - I prefer the all-dashed approach. Current, alt1, or alt3 seem best for that. Andrew Gray (talk) 19:50, 5 October 2016 (UTC)
  • Andrew Gray (talk · contribs), alt 6 and 7 both have partially closed shackles (basically the same as alt 4/5, but in blue). The big version had the closed shackle by mistake. Headbomb {talk / contribs / physics / books} 21:06, 5 October 2016 (UTC)
    • Thanks for the clarification. I think the partly-closed shackle is still a bit hard to distinguish when seen in the small icon - easy to mistake for fully closed since it only has a couple of breaks in one quarter. So current/alt1/alt3 (fully dashed) still have the edge. Andrew Gray (talk) 11:18, 6 October 2016 (UTC)

Third lock nailed

From what I can tell above, there's a rough consensus (if not full consensus) for the fully-closed red lock above (aka "the third lock"). I think we should make that change in the sandbox regardless of the other locks. Does anyone (dis)agree? --Izno (talk) 20:42, 10 October 2016 (UTC)

Agreed that it's very likely what the final choice will be / there is consensus for it. But I don't really see the point in making the changes right now. We might need to have a community wide RFC on this, and just go with the preference of the majority. Headbomb {talk / contribs / physics / books} 21:28, 10 October 2016 (UTC)

Nailing down the first lock

I think everyone agrees the fully-open lock (aka "the first lock") should be green and open (in the latch). Let's figure out whether we want the middle of the lock to have a small circle or completely open so we can nail that lock down. --Izno (talk) 20:42, 10 October 2016 (UTC)

The first lock is kinda contingent on the second lock, and vice versa. Say we go for File:Lock-yellow-alt-4.svg (dot), then that likely means File:Lock-green-alt.svg (no dot). If we go instead with for File:Lock-yellow-alt-5.svg (half circle), then either File:Lock-green.svg (dot) or File:Lock-green-alt.svg (not dot) are viable.

Likewise, if we decide on File:Lock-green.svg (dot), then that gets rid of File:Lock-yellow-alt.svg, File:Lock-yellow-alt-4.svg, File:Lock-yellow-alt-6.svg. If if we decide on File:Lock-green.svg (no dot), then all yellow/blue locks are viable choices. Headbomb {talk / contribs / physics / books} 21:25, 10 October 2016 (UTC)

RFC?

I think we should hold an RFC on the matter of lock designs. I've drafted something at User:Headbomb/sandbox3. Comments before I shoot this at the village pump? Or maybe this should be posted here? Headbomb {talk / contribs / physics / books} 22:27, 10 October 2016 (UTC)

Nice! Any chances you could also include Trappist's last proposal (two different shapes for the two intermediate access levels)? I think it might be worth pushing the changes in the live module before holding that RFC. That might sound a bit awkward, but here are a few reasons:

• If the change goes live now, immediately no new lock will be added to citations (because they need to be explicitly added with |id-access=). Except the existing green ones, which are already live and against which I have not witnessed any rebellion. Some people might start tagging some |url-access=subscription but it will be marginal (otherwise a bot approval request needs to be filed).
• This lets us submit the OAbot for approval (as it only adds green locks)
• Having a working CS1 code will help people who are not familiar with the sandbox to try out these new features, so that they can really understand what the RFC is about.
• Holding an RFC now and waiting for it to complete will postpone the next update of the live code even more.
• Pushing the changes to the live module enables us to publish the Signpost article and advertise the RFC there.

If the outcome of the RFC was a very controversial decision, surely the RFC should be held first, but I have the feeling here that we are all mostly fine with most solutions.

− Pintoch (talk) 06:28, 11 October 2016 (UTC)

You make good points. I agree we should roll out. Let go with the 'original/current' locks so the discussion/RFC is easier to follow, and change them after the RFC is concluded. Headbomb {talk / contribs / physics / books} 10:53, 11 October 2016 (UTC)

This rfc is about too many things. It starts out with the icon designs then shifts to how and when icons should be displayed (without stating how editors will cause icon display) and then shifts again to auto-linking. Too much choice, too much for editors to wrap their brains around. How long has it taken us, who have a strong interest, to get to this point? For editors who don't have such strong interest, so much choice may cause them to make choices that aren't fully considered or may cause them to make no choice at all; both of which are detrimental to the outcome of the rfc. If the goal is lock design, keep the rfc to just that topic: lock design. Defer aspects 2 and 3 to later rfcs if rfcs are necessary for these topics.

All lock icons in the rfc should have the tool tips and alt text.

Use the correct markup in the citation mock-ups so that editors don't see both the lock icon and the typical external link icon. Show the citations as they would actually be rendered by the templates.

One quibble I have with rfcs is that the authors choose generic section headings Vote (should be !vote), Discussion, etc which are meaningless when looking at my watchlist or a talk page history. Choose heading titles that identify the rfc to which the section headings belong.

The Choice 1, Choice 2, Choice 3 headings do not necessarily instruct editors to make three separate choices but at first blush may appear to be three offerings from which editors are to make one choice. Perhaps:

Lock design step 1) choose lock colors: Green–Yellow–Red (GYR) or Green–Blue–Red (GBR)

Lock design step 2) choose shackle style: 100% dashed or 50% dashed or 25% dashed

Lock design step 3) choose body style: Dotted–Half–Full (DHF) or Empty–Half–Full (EHF) or Empty–Dotted–Full (EDF)

Under the !vote heading, add text that tells editors what they are expected to do in the rfc: express opinion on three separate characteristics of the lock icon designs.

Do not lead the !voting. Another of my quibbles with rfcs is the tendency of rfc authors to write an rfc in such a way that !voting editors know the outcome that the author desires. Once proposed, we have thirty days or so to express our opinions; we can and should hold off until later. Neutral language throughout.

The pseudo-rfc that was held here started with a couple of options but then ballooned to nearly a dozen choices. In the real rfc, that must not happen. Once committed, except for glaring error, the rfc must not be edited in any way. We do not want to take the chance that such an edit might possibly negate an editor's !vote as happened here in the pseudo-rfc.

For interested editors, we should provide links to all of the discussions that got us here.

The original lock icons (A1 – what does A1 mean?) directly above the Dotted Green / Yellow / Red (DGYR) pseudo-heading should be removed so that editors don't think that that color/shackle/body combination is one that we want them to include in their !vote considerations.

—Trappist the monk (talk) 10:54, 12 October 2016 (UTC)

Good feedback Trappist the monk (talk · contribs). Glad I held off posting to the village pump until you chipped in. Take a look at it now, see if I overlooked anything. I'm fine will withholding my !vote so it doesn't lead the sections, it's just there for now because I'm still forming an opinion on some of those matters, and writing it down helps to crystallize my thoughts. Headbomb {talk / contribs / physics / books} 12:03, 12 October 2016 (UTC)

Not happy with the new section headings. Granted that 'Aspect A1) Color: Green–Yellow–Red (GYR) vs Green–Blue–Red (GBR)' etc is atypical but it is not instructive whereas 'Lock design step 1) choose lock colors: Green–Yellow–Red (GYR) or Green–Blue–Red' tells the reader that this heading is part of the lock design rfc, that this heading is the first step in a multi-step process, that under this heading the reader is to make a choice between these two things. 'First RFC' does not identify this rfc in a watchlist as the lock design rfc. Every heading in the rfc should in some way include a brief mention of the rfc subject: 'RFC lock design' → 'RFC lock design: !vote' → 'RFC lock design: discussion' so that editors looking at their watchlists immediately know that the lock design rfc was recently edited without the need to follow the link into the rfc to figure out which one (of possibly multiple rfcs) this one is.

For the color choice, I wonder if simple display of color against the two background colors without the influence of the lock shapes would be better:

Here the choice is blue or yellow. Is it necessary to show the other two colors?

Because the shackle shape choice only applies to the limited locks, is there a need to show the other two? Perhaps this step in the process selects the whole limited access lock from the six possible shapes.

1. |
2. |
3. |
4. |
5. |
6. |

Similarly, the last choice is the free lock body shape so the choice reduces to choosing one of these two:

1. 
2. 

There is still no text under the !vote heading that tells the reader what is expected of them for this rfc.

The second instance of the original lock icons must be removed so that readers are not confused into thinking that the originals are an option (unless they are, in which case, that choice must be explicitly stated). Is it necessary to include the original locks at all?

May I copy edit the rfc?

—Trappist the monk (talk) 11:44, 13 October 2016 (UTC)

I've cut down and simplified a few options per the above. Feel free to copy-edit the RFC. However, we should really roll out the updated citation template code, so hopefully that can be done over the weekend / sooner. Headbomb {talk / contribs / physics / books} 15:10, 13 October 2016 (UTC)

a.	/ /
b.	/ /
c.	/ /
d.	/ /
e.	/ /
f.	/ /
g.	/ /
h.	/ /
i.	/ /
j.	/ /
k.	/ /
l.	/ /
m.	/ /
n.	/ /
o.	/ /
p.	/ /
q.	/ /
r.	/ /

Meh.

I chose blobs of color within areas of the black and white backgrounds because the overall white of the rest of the screen effects how the locks appear within a small black background surrounded by white. Also because the first aspect choice is color, there is no need to complicate the decision process by including any locks. Reduce the information presented to only that which is necessary for editors to make a decision.

In an attempt to minimize any perception of my preferences in these choices, in my suggested changes I alternated color for the shape choices; that isn't possible for the green lock.

Because the individual choices are more limited now, the columnar locks with their cryptic initialisms can probably be replaced with the illustration at right. In that table, there is a single change row-to-row which I think includes all of the possible choices.

—Trappist the monk (talk) 11:30, 14 October 2016 (UTC)

Wait for url generation?

Now that I think of it, it might be best to wait for #Automatic_url_generation before deploying. Headbomb {talk / contribs / physics / books} 12:39, 30 September 2016 (UTC)

I remain opposed to automatic urls for the reasons that I stated there.

—Trappist the monk (talk) 11:05, 1 October 2016 (UTC)

Which means we would treat free full version identifiers inconsistently, and will add lots of useless clutter in print versions. Automatic main-linking is a good thing, and would be so immensely useful in the case of free bibcodes. Headbomb {talk / contribs / physics / books} 13:23, 1 October 2016 (UTC)

As I've said before, I think that auto-linking PMC is wrong. Compounding that wrong by auto-linking all the other free-to-read identifiers does not, in my mind, solve the problem. For consistency, we should disallow auto-linking of PMC especially if we can get around the lock icon issues that remain.

You used the printed clutter argument before. I did not understand it then and do not understand it now. When I print a page of citations, there is no clutter of the kind that you suggest must already be present. What are you doing that shows clutter problems?

—Trappist the monk (talk) 18:29, 1 October 2016 (UTC)

Copy {{cite journal |last1=Bar |first1=Krzysztof |last2=Vicary |first2=Jamie |title=A 2-Categorical Analysis of Complementary Families, Quantum Key Distribution and the Mean King Problem |url=https://dx.doi.org/10.4204/EPTCS.172.23 |journal=Electronic Proceedings in Theoretical Computer Science |date=28 December 2014 |volume=172 |pages=316–332 |doi=10.4204/EPTCS.172.23}} in your sandbox and select "printable version" from the print/export toolbar. You'll see the issue. Headbomb {talk / contribs / physics / books} 13:55, 11 October 2016 (UTC)

Strange, it doesn't do that anymore. That is very, very weird. How is someone to know what link is meant? I'll make a thread on the village pump to restore that behaviour / update it. Headbomb {talk / contribs / physics / books} 13:59, 11 October 2016 (UTC)

I agree that this is a feature worth being debated (and the |pmc= case shows that editors value it), but it is an important proposal which might have unexpected side effects. The last update of the live module dates back to a few months ago, so if we want to include the change you propose, it will probably take a long time and block other changes awaiting the live module update. I think it would be simpler to clear the backlog of pending updates and discuss that afterwards. − Pintoch (talk) 14:26, 1 October 2016 (UTC)

We can deploy now I suppose, but it would have been nice to include this in the Signpost piece I'm writing which details everything. I don't think it would take much more than a week to develop and tweak automatic url generation though. Headbomb {talk / contribs / physics / books} 14:45, 1 October 2016 (UTC)

(←) I agree with Pintoch dated 1 October. Your draft can still make reference to the proposal, if desired. --Izno (talk) 20:15, 10 October 2016 (UTC)

Tooltips

Tooltip definitions: "free registration" and "paid subscription" may be oxymorons. A "paid registration" is a subscription; a "free subscription" is a registration. I would do away with the "free" and "paid" modifiers. 72.43.99.146 (talk) 14:32, 30 September 2016 (UTC)

Sorry I mean the link text for the icons, which appears as a tooltip. 72.43.99.146 (talk) 15:16, 30 September 2016 (UTC)

An oxymoron requires contradictory terms e.g. Dark light. "Free registration" and "Paid subscription" are at best somewhat redundant, but this is the good kind of redundancy because it makes it clear that free/paid is the difference between registration vs subscription. Because technically, you can have free subscriptions (e.g. I'm subscribed to several mailing lists, and I didn't pay anything for that), and paid registration (e.g. when I sign up at a conference, I register).

Subscription and registration. 184.75.21.30 (talk) 21:58, 30 September 2016 (UTC)

Google search: "Free subscription", "Paid registration". Headbomb {talk / contribs / physics / books} 13:26, 1 October 2016 (UTC)

Marketing terms (confirmed by the majority of search results), that have no place in an encyclopedia. 72.43.99.138 (talk) 14:33, 1 October 2016 (UTC)

Hardly. I've got dozens of mailing list subscriptions, and those aren't mailing list registrations. Likewise, I've paid to be registered for several things, and those aren't subscriptions. See in particular definition 1.b here "An agreement to receive or be given access to electronic texts or services, especially over the Internet", with no reference to whether money was exchanged. Headbomb {talk / contribs / physics / books} 14:42, 1 October 2016 (UTC)

I think terms should be used according to the accepted definition from reliable sources (the free dictionary? we might as well be bringing up Wikipedia as a source), not as people abuse them or because promoters (publishers, conference organizers, universities, the WMF etc.) want people to buy their product. A subscription is a payment in advance. There is no such thing as a free subscription; that is something else. Are you a healthy sick person? Registrations do not involve payments (though they are not free, they are exchanges: you provide information, they provide the product). A paid registration is not a registration, it is a purchase. But don't let me upset the newspeak, obfuscation, and resulting incomprehensible documentation around here; do carry on. 72.43.99.138 (talk) 13:55, 2 October 2016 (UTC)

Deploy

Let's deploy this thing. It's been two months and a half since the last update. The code is stable and tested. Nothing will budge till the #RFC? discussed above is concluded, and that RFC can't start till the new code is rolled out. Headbomb {talk / contribs / physics / books} 11:41, 14 October 2016 (UTC)

@Trappist the monk: I agree, what do you think about that? − Pintoch (talk) 11:40, 16 October 2016 (UTC)

Are you really ready? In the past, for changes that I have made to cs1|2, I have created the initial documentation, I have created categories, I have created help text, etc. If all of those things are done, then the next step is to make the one-week-ahead-of-deployment announcement.

Real life for me is busier than normal so I haven't the time to do all of these things for you.

—Trappist the monk (talk) 12:24, 16 October 2016 (UTC)

Well, the doc and categories can be taken care of pretty quickly, I can do those tonight or tomorrow. Not really sure what exactly is help text, but I can't see any of that taking more than a day or two to take care of. Headbomb {talk / contribs / physics / books} 12:30, 16 October 2016 (UTC)

I have created Category:CS1_errors:_⟨id⟩-access_without_id, added error messages to Help:CS1 errors and started some documentation at Help:Citation Style 1. Improvements welcome! − Pintoch (talk) 17:00, 16 October 2016 (UTC)

I have also created Category:CS1_errors:_citeseerx and the relevant section of Help:CS1 errors. − Pintoch (talk) 18:41, 16 October 2016 (UTC)

I chose ‹The template Category link is being considered for merging.› Category:CS1 error: param-access as a category name because it is not specific to identifiers alone. Identifiers, and 'id', have a specific meaning within cs1|2 so the use of 'id' in the name of the new category implies that the category holds only pages with identifier access level errors. |url-access= applies to |url=, which most definitely is not an identifier, should therefore not be made part of this newly named category but should, instead, have its own, something I was attempting to avoid by the use of the generic 'param-access' name I chose. Why did you undo that work?

—Trappist the monk (talk) 19:21, 16 October 2016 (UTC)

Oops, sorry about that, for some reason I misread the thread and thought Headbomb's proposal was the latest one. No idea why, really. (I even agreed with your change earlier…). Let me fix that. − Pintoch (talk) 20:00, 16 October 2016 (UTC)

At Help:Citation Style 1#Deprecated parameters you wrote that |subscription= and |registration= are deprecated. Where did that decision get made? Did we ever make such a decision?

—Trappist the monk (talk) 21:52, 16 October 2016 (UTC)

This removed ['DoiAccess'] = {'doi-access'}. Not really sure what it does, but should we also remove ['UrlAccess'] = {'url-access'}?

As for a specific decision on deprecating |subscription= / |registration=, it as never explicitly !vote on, but the issues with those parameters were mentioned several times, as was deprecation was mentioned several times and I don't recall anyone raising an objection. Headbomb {talk / contribs / physics / books} 23:22, 16 October 2016 (UTC)

I object (though not strenuously) to the deprecation of |subscription= / |registration= without further discussion. Apologies if I missed something, but I did not see that explicit proposal. I have tuned out of the (to my mind) esoterica of the -access parameters and the padlocks, but these two parameters are used quite widely, I believe. – Jonesey95 (talk) 03:59, 17 October 2016 (UTC)

An insource search for |subscription=yes and for |registration=yes finds 9800-ish and 1300-ish uses of these parameters.

—Trappist the monk (talk) 10:03, 17 October 2016 (UTC)

About 'DoiAccess': no we should not remove 'UrlAccess', it is still used in the code. 'DoiAccess' was not. It was a leftover from the first implementation that only covered |doi-access=.

@Headbomb: I see you have added an error message category and help text for |biorxiv=. But as far as I can tell this error message is never raised by the code: no validation is done on the biorxiv id (just like for a bunch of other ids). So either we add some validation, or we should remove this category and help text, I think.

About the proposed deprecation: Trappist, you agreed we had to deprecate these if the new |param-access= system was rolled out. The relevant discussion is here. Anyway I did not deprecate them in the code: they will still work as expected. Feel free to restore the original documentation if you feel that we did not discuss that enough… − Pintoch (talk) 05:06, 17 October 2016 (UTC)

By the way, in the section just below this one, Headbomb called for the said deprecation as a wrap-up of what had been agreed in the previous discussion (linked above). No concern was raised and this was almost a month ago already. I agree the debate is sometimes hard to follow but I am not sure that turning it into a lengthy formal discussion and vote would help… − Pintoch (talk) 05:26, 17 October 2016 (UTC)

(edit conflict) Agreeing that they should be deprecated is not the same as saying we had to deprecate them. Please don't put words into my mouth that I have not spoken. Those two parameters do not have to be deprecated. I just wanted to make sure that there is a firm decision to deprecate. If there is, then the whitelist settings for those two parameters should be set to false so that they are actually treated by the module as deprecated.

—Trappist the monk (talk) 10:03, 17 October 2016 (UTC)

Yes, we should add validation for |biorxiv=. I personally feel deprecation has been discussed enough. There's just too many issues with |registration=/|subscription=, and it makes no sense for have both |registration=yes/|subscription=yes and |url-access=registration/|url-access=subscription.

The real question is how do we deprecate? Do we consider |registration=yes as an alias of |access=registration for this update? This way if we misread the community / didn't think of some aspect, we can un-deprecate without great pains and we don't have to deal with thousands of error messages. And if we get no reasonable objections, we can send bots to convert |registration=yes to |url-access=registration and cleanup articles before the next code update, when we'll throw a proper error message. I'm not really worried about misreading the community/not having thought of something, but I'm partial to that option just so that bots have a chance to cleanup things before we throw error messages.

Or is it too complicated/dirty code to make |registration=yes an alias of |url-access=registration, and we should just go all in and throw the error message now. Headbomb {talk / contribs / physics / books} 09:44, 17 October 2016 (UTC)

Ok, I think there was a misunderstanding. By writing in the documentation that these parameters are deprecated I did not intend to change anything in the code to reject these parameters. I am totally against adding lots of error messages for all occurrences of |subscription= and |registration= in the coming update. So it seems that I should rather have written that the new system is preferred over the old one. Once the new system is deployed, we can let a few months to see how the community reacts, and then think about running a bot to transform the unambiguous uses of the old parameters to the new ones. (I don't think it is a good idea to do an alias, because of the possible ambiguous cases.) I just think it makes sense to point editors to the new system for the edits they do after the roll-out. But I am also happy with not stating any preference in the doc, really. − Pintoch (talk) 10:16, 17 October 2016 (UTC)

As far as I can tell, all known bugs in the sandbox have been resolved, docs and help messages have been written and categories have been created. Are we ready to deploy? − Pintoch (talk) 16:20, 18 October 2016 (UTC)

Template documentation for the |*-access= parameters? Where is that? I suppose, if you are feeling adventurous and have nothing better to do with your time, you might make appropriate additions to the abomination that is TemplateData. Or not. I don't care if that latter task is ever accomplished, but, these new parameters must be documented in the normal template documentation; even if, as a certain IP editor takes pains to remind us, that documentation is inadequate and sucks.

—Trappist the monk (talk) 19:55, 18 October 2016 (UTC)

Help:Citation_Style_1#Access_level_of_identifiers? Headbomb {talk / contribs / physics / books} 19:59, 18 October 2016 (UTC)

I just realized each CS1-based template could have its own specialized doc, such as Template:Cite_journal/doc… They should be updated as well, I guess. − Pintoch (talk) 20:19, 18 October 2016 (UTC)

Template documentation and TemplateData updated. I suggest we announce the deployment so that the documentation and the actual code do not stay out of sync too long. The docs can still be improved but this can be done during the week before deployment. − Pintoch (talk) 08:35, 20 October 2016 (UTC)

Ok. Announcement this weekend.

—Trappist the monk (talk) 09:34, 20 October 2016 (UTC)

Why are we now no longer depracating |registration= and |subscription=? Let's get rid of them, both for simplicity's sake and so we don't have to deal with error messages for the inevitable case of having both |registration=yes and |url-access=registration, or |registration=yes |url-access=subscription. They can be put as aliases of |url-access=registration/|url-access=subscription for now if we want a transition period, but they need to go. Headbomb {talk / contribs / physics / books} 17:17, 18 October 2016 (UTC)

Well, surely the case of conflicts between the old and the new systems can be avoided: it is up to the editors or bots who introduce them! If we deploy the sandbox as it is now, no new error should be added. Again it is not acceptable to create an alias. Here is an example taken from Brownian motion:

• Before: Morozov, A. N.; Skripkin, A. V. (2011). "Spherical particle Brownian motion in viscous medium as non-Markovian random process". Physics Letters A. 375 (46): 4113–4115. Bibcode:2011PhLA..375.4113M. doi:10.1016/j.physleta.2011.10.001. {{cite journal}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)

If we put an alias, here is what will happen (I just replace |subscription=yes by |url-access=subscription):

• After: Morozov, A. N.; Skripkin, A. V. (2011). "Spherical particle Brownian motion in viscous medium as non-Markovian random process". Physics Letters A. 375 (46): 4113–4115. Bibcode:2011PhLA..375.4113M. doi:10.1016/j.physleta.2011.10.001. {{cite journal}}: |url-access= requires |url= (help)

I don't have the exact figures but I can produce at least a few hundreds of examples like that. There are other cases where the alias would not raise any error, but would display false information. This example is taken from Clathrina:

• Before: Klautau, Michelle; Azevedo, Fernanda; Cóndor-Luján, Báslavi; Rapp, Hans Tore; Collins, Allen; Russo, Claudia Augusta de Moraes (2013). "A Molecular Phylogeny for the Order Clathrinida Rekindles and Refines Haeckel's Taxonomic Proposal for Calcareous Sponges" (PDF). Integrative and Comparative Biology. 53 (3): 447–461. doi:10.1093/icb/ict039. {{cite journal}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)
• After: Klautau, Michelle; Azevedo, Fernanda; Cóndor-Luján, Báslavi; Rapp, Hans Tore; Collins, Allen; Russo, Claudia Augusta de Moraes (2013). "A Molecular Phylogeny for the Order Clathrinida Rekindles and Refines Haeckel's Taxonomic Proposal for Calcareous Sponges" (PDF). Integrative and Comparative Biology. 53 (3): 447–461. doi:10.1093/icb/ict039.

So, I think the migration to the new system should be done with a bot. This implies not disrupting the existing parameters in the coming update. (By the way, these examples seen in the wild make our case for the ambiguity of the existing parameters pretty nicely, I think.) − Pintoch (talk) 17:59, 18 October 2016 (UTC)

Hmm, the first example can really only be taken care of after the RFC to see if we want to allow |doi-access=subscription. I guess we can wait after that to deprecate. Headbomb {talk / contribs / physics / books} 18:03, 18 October 2016 (UTC)

Following the discussions regarding this is effectively impossible, so even as a pretty technical editor and enthusiastic user of these templates, I have no idea what you're now actually proposing to do. Before you "deprecate" anything here I would strongly urge that you post a comprehensive but succinct summary of the planned changes. Because I get really concerned when, absent context, I see suggestions that a new |url-access= param can replace |subscription= (even for cites, like the majority of those I use these templates for, that have a DOI or JSTOR number but no URL). Some practical way for more, and more diverse, eyeballs to check your assumptions before deploying would be a very good idea (unless you enjoy the angry villagers forming up at your door with torches and pitchforks). --Xover (talk) 18:20, 18 October 2016 (UTC)

Basically, deprecation would mean throwing away |registration=/|subscription= in favour of the new system |url-access=registration/|url-access=subscription. However, as mentioned above, we can't really throw them away now, because sometimes |registration=/|subscription= are used to refer to whether identifiers require registration/subscription, and we don't currently support |doi-access=registration/|doi-access=subscription. Whether we should (and I think we should), will be addressed by an upcoming RFC (see RFC draft) on what the final behaviour of the template should be with respect to access locks. Headbomb {talk / contribs / physics / books} 18:28, 18 October 2016 (UTC)

Thanks. That does alleviate my concerns, particularly that you're planning to run an RFC on it. In any case, the main thrust of my "intervention" was to not rely solely on the discussions here, because they're impossible to follow and risk falling prey to the "echo chamber" effect. In various other places I've occasionally had to remind people of this, but it seems in this case it was not needed. Carry on... :) --Xover (talk) 03:57, 19 October 2016 (UTC)

Not quite true. Deprecation does not mean throwing away |registration=/|subscription= in favour of the new system. It means that for a time, could be months, could be years (as has been the case of |coauthor(s)=), the deprecated parameters exist in parallel with the new system. The old parameters are gradually replaced by the new until the count of old parameters drops to an insignificant number. When that happens, then and only then, are the old parameters 'thrown away'.

To deprecate, we simply set ['registration'] = false and ['subscription'] = false in Module:Citation/CS1/Whitelist and wait. As pages are edited or they work their way through the job queue, cs1|2 templates with those parameters will be marked with an error message and the pages will be added to ‹The template Category link is being considered for merging.› Category:Pages containing cite templates with deprecated parameters. Editors may 'fix' the errors, bots can 'fix' the errors, AWB scripts can 'fix' the errors.

—Trappist the monk (talk) 10:56, 19 October 2016 (UTC)

url-access support

Per the above discussion, we should now implement

• |url-access== free ()/registration ()/limited ()/trial()/subscription ()

And deprecate |registration=/|subscription=

We could also

• leave |url-access=free out
• make |access= an alias of |url-access=

The hover text and file versions for the locks should match (mine are a bit different). Headbomb {talk / contribs / physics / books} 17:02, 24 September 2016 (UTC)

I thought that the parameter for the url was to be |access=. It is implemented to some extent but is pretty severely broken:

{{cite book/new |title=Title |url=//example.com |url-access=subscription}}

Title.

Pintoch, did you break it?

—Trappist the monk (talk) 17:22, 24 September 2016 (UTC)

Oops, sorry about that. Let me investigate. − Pintoch (talk) 18:32, 24 September 2016 (UTC)

Well, it could be |access=, but then I saw the current error message so I was like... well maybe it's better to have it as |url-access=? I don't have strong feelings here, although I think it would be good to have both |access= and |url-access= as alias of each other. Headbomb {talk / contribs / physics / books} 19:07, 24 September 2016 (UTC)

@Trappist the monk: The bug was introduced when I added support for |access=, because now that the title can be wrapped inside a <span>, the following check for an empty citation triggers when there is only a title:

if string.len(text:gsub("<span[^>/]*>.-</span>", ""):gsub("%b<>","")) <= 2 then

I believe this check was introduced with the idea that all things enclosed by <span> tags were peripheral, non-essential pieces of metadata: this is not true anymore as adding |access=subscription encloses the title with a <span>. So, this check should be replaced by something simpler (should I write "cleaner"). Any idea how? What about string.len(text:gsub("%b","")) == 0? There is probably a reason why the original check was so complicated, but the test suite does not help much to understand. Concerning |url-access= vs |access=, I am happy with both, but maybe |url-access= is indeed more coherent with the |id-access= scheme. − Pintoch (talk) 19:17, 24 September 2016 (UTC)

I suspect that you're right about the <span>...</span> tags. I changed that line to use <cite>...</cite> and it seems to work. I'm not inclined to change it further until I have the time to actually think about what it is that its doing. It's from before my time, and like so much of that, undocumented.

But, since we're talking about code, can we not use camelCase? For the most part, the camelCase form is used only in calls to the Scribunto library and is the legacy form used for meta-parameter names. As long as I've been working on this code, I have tried to adopt a uniform naming convention.

—Trappist the monk (talk) 19:42, 24 September 2016 (UTC)

Got it, I just changed customAccess to custom_access. − Pintoch (talk) 20:43, 24 September 2016 (UTC)

Clearly, the change I made to the code snippet above (<span>...</span> to <cite>...</cite>) was wrong. It makes no sense to look for <cite>...</cite> tags before they are added to the output. This part of the snippet:

text:gsub("<span[^>/]*>.-</span>", "")

looks for and replaces span tags with an empty string. Once that's done, this bit:

:gsub("%b<>","")

looks for and replaces other html-like markup with an empty string (anything enclosed in <...>; cs1|2 adds <q>...</q> and <b>...</b>)

I am a bit perplexed by the pattern in the first replacement:

"<span[^>/]*>.-</span>"

The pattern matches everything between the opening and closing tags and replaces the lot with nothing. So, in this case, where text has the value:

<span class="plainlinks">[//example.com ''Title'']</span><span style="margin-left:.1em">[[File:Lock-red.svg|9px|link=|A (paid) subscription is required to access this source]]</span>.

everything except the final dot is replaced by nothing. Why?

I wonder if the pattern and replacement should have been:

text:gsub("<span[^>/]*>(.-)</span>", "%1")

This captures the content and uses that as the replacement value so only the <span>...</span> tags are removed leaving the content behind:

[//example.com ''Title'']

which gives string.len() something to count besides the dot.

Except that, once upon a time, there was code that added hidden comments to the module output for debug information. Those comments were enclosed in <span>...</span> tags so apparently, the first replacement pattern was added to deal with them. It makes sense that for those hidden comment <span>...</span> tags, removal of the whole is appropriate. That form of debugging has since been removed and we are now occasionally enclosing elements of the citation in <span>...</span> tags so we should not be discarding the content of those tags in the process of doing this test.

I have reverted my edit and modified the test as described above.

—Trappist the monk (talk) 11:54, 25 September 2016 (UTC)

Awesome, thanks a lot! Your new version looks much more sensible indeed. − Pintoch (talk) 13:36, 25 September 2016 (UTC)

I have changed |access= to |url-access=, given the arguments above (and also from the previous discussion):

• The current error message (suggesting to use |access-date= instead of |access=) indicates that some editors might write |access= when they think |access-date=, so they could be confused by the new meaning of |access=
• Using |url-access= is more consistent with the |id-access= schema
• 'access' alone is too generic, not informative enough
• This change underlines that the access level is tied to the |url= unlike |subscription= and |registration=.

Currently |access= is rejected (it is not an alias of |url-access=), essentially because of the first argument. − Pintoch (talk) 08:58, 27 September 2016 (UTC)

Category names. Perhaps not these: ‹The template Category link is being considered for merging.› Category:Pages using citations with url-access and no URL and ‹The template Category link is being considered for merging.› Category:Pages using citations with id-access and no id? For quite some time now, new error categories have been named: 'Category:CS1 errors: <something>' where <something> is a brief descriptor of the category's purpose. I might suggest: ‹The template Category link is being considered for merging.› Category:CS1 errors: url-access without URL and ‹The template Category link is being considered for merging.› Category:CS1 errors: id-access without id.

—Trappist the monk (talk) 09:40, 27 September 2016 (UTC)

That's much better indeed, I have changed that. Actually, is it useful to keep these two categories separate? It is quite simple to merge them (we can remove the error message for |url-access= and use the one for |id-access= with id=url). It seems harder to split the one for |id-access= into specialized ones for |doi-access=, |hdl-access= and the others without adding some complexity to the Lua code. − Pintoch (talk) 13:01, 27 September 2016 (UTC)

I think if anything, the category should be

‹The template Category link is being considered for merging.› Category:CS1 errors: ⟨id⟩-access without id to make it clear that people shouldn't look for a literal |id-access= but for |foobar-access=. But ideally, the error/categorization would be on a per-parameter basis, with ‹The template Category link is being considered for merging.› Category:CS1 errors: doi-access without id being a subcategory of ‹The template Category link is being considered for merging.› Category:CS1 errors: ⟨id⟩-access without id. Headbomb {talk / contribs / physics / books} 11:51, 14 October 2016 (UTC)

Because the |url-access= error is essentially the same as the |<id>-access= error, because the error messages have identical static text, because the 'fix' for these errors is the same, I see no point in having two separate categories, two separate error message handlers. I have combined these into a single error message using the single ‹The template Category link is being considered for merging.› Category:CS1 error: param-access.

If ever in future there are so many of these errors that individual parameter categories are desirable, we can contemplate that then.

—Trappist the monk (talk) 11:45, 15 October 2016 (UTC)

Excellent! I agree it's simpler like that. Thanks for adding the missing category by the way. - Pintoch (talk) 11:58, 15 October 2016 (UTC)

archive-url and url-access

How does url-access interface with archiveurl if at all? For example sometimes the live link is paywalled while a archive link version is not. Editors will add an archivelink version to get around the policy block. I don't think it is terribly common but does happen. If deadurl=yes, will url-access show a lock for the original dead link or for the archive link or both? -- GreenC 17:27, 16 October 2016 (UTC)

Currently, the lock is still added to the title, which points to the archived version:

• Doe, John. "Title". Archived from the original on 2009-04-21. {{cite journal}}: Cite journal requires |journal= (help)

I guess it should rather be on the original link. Should I change that? − Pintoch (talk) 18:31, 16 October 2016 (UTC)

I would say the lock symbol should be on the original link rather the archive link. It's unknown what the status of the archive link is. -- GreenC 14:48, 18 October 2016 (UTC)

I have swapped the icon, see example above. − Pintoch (talk) 15:11, 18 October 2016 (UTC)

New lab tool potentially of interest to watchers of this page

You may wish to review the briefing on the Template Parameters tool in the Signpost at Wikipedia:Wikipedia Signpost/2016-09-29/Technology report#See how template parameters are used. --Izno (talk) 12:52, 29 September 2016 (UTC)

Nice tool; I've just made {{Template error report}} for use in template documentation. The tool relies on Wikipedia:Template data. Do any CS1 templates use that? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:25, 29 September 2016 (UTC)

I believe that all CS1 templates have TemplateData definitions. I don't use Visual Editor, so I don't know how it works, but putting "cite web" into the tool leads to some fascinating results. Very useful. – Jonesey95 (talk) 18:50, 29 September 2016 (UTC)

Of sorts. I think that it was a fair assumption that (a) few read the doc (b) even fewer can make sense of it. This tool confirms that assumption, imo. Btw, as indicated, it applies only when any parameters are used. 72.43.99.146 (talk) 14:24, 30 September 2016 (UTC)

PMC limit bumped

I noticed a few valid PMCs being flagged in Category:CS1 errors: PMC, so in this edit I bumped the validation limit from 5000000 to 5100000. I don't know what the rate of increase is, so I went for what seemed to be a minimal fix, having noted that the flagged PMCs were in the 5020000 range. Would it be worth raising the limit further? {{Nihiltres |talk |edits}} 14:11, 30 September 2016 (UTC)

It's fixed in the sandbox. See Help_talk:Citation_Style_1#PMC_error_checking_adjustment. Headbomb {talk / contribs / physics / books} 14:15, 30 September 2016 (UTC)

OK, good. {{Nihiltres |talk |edits}} 14:17, 30 September 2016 (UTC)

Protected edit request on 7 October 2016

Two instances of the bad style "needs to" should be replaced by "must": Please change the quote needs to include terminating punctuation to the quote must include terminating punctuation.

Eric ^talk 02:57, 7 October 2016 (UTC)

It looks like you figured out that the documentation is not protected. – Jonesey95 (talk) 03:00, 7 October 2016 (UTC)

Partially, but for some reason I couldn't get at it here: Help:Citation_Style_1#Quote until just now. Just took care of it. Thanks. Eric ^talk 12:11, 7 October 2016 (UTC)

Template for deletion: cite archives

The template {{cite archives}} has an ongoing TfD at Wikipedia:Templates_for_discussion/Log/2016_October_7#Template:Cite_additional_archived_pages. Seeking any input regarding the deletion, as well as any input on the idea that CS1|2 could support multiple archives such as |archiveurl2= and this merge functionality here. Thanks. -- GreenC 19:19, 7 October 2016 (UTC)

Volume parameter absent from typeset output from Cite conference

This is about {{Cite conference}}. Consider this citation  and this citation, the second differing from the first by the inclusion of |volume=2. As can be seen below, this volume information is not typeset.

References

The documentation states however:

volume

For one publication published in several volumes. Displays after the title and series fields; volumes of four characters or less display in bold.

Looks like a bug? Best wishes. RobbieIanMorrison (talk) 13:18, 14 October 2016 (UTC)

Because you have identified the conference proceedings as a book (you used |book-title=Proceedings of ABC 2000), |volume= does not apply. Had you identified the proceedings as a journal (had you used |journal=Journal name and |title=Proceedings of ABC 2000), then |volume= (and |issue=) apply.

{{cite conference |last1=Frog |first1=Bill |title=On water and wetness |date=1 January 2000 |conference=ABC 2000 |editor-last1=Fly |editor-first1=Felicity |title=Proceedings of ABC 2000 |journal=Journal of Whatever |publisher=Academic Press |location=London, UK |pages=659–668 |volume=2 |issue=5}}

Frog, Bill (1 January 2000). Fly, Felicity (ed.). Proceedings of ABC 2000. ABC 2000. Journal of Whatever. Vol. 2, no. 5. London, UK: Academic Press. pp. 659–668.

—Trappist the monk (talk) 13:36, 14 October 2016 (UTC)

It's still a bug though. Books can have volumes. Headbomb {talk / contribs / physics / books} 14:18, 14 October 2016 (UTC)

A few more things: "the full parameter set" does not include |series=, however the parameter displays values when properly used with |book-title=. Yet when both |series= and |volume= are used, volume does not display. To compound the schizophrenia, there is this section: Template:Cite_conference#Edition, series, volume. 65.88.88.46 (talk) 15:46, 14 October 2016 (UTC)

Here is an example from real-life where a proceedings is published in multiple volumes:

{{cite conference/new |vauthors=Vos F, Delaey L, De Bonte M, Froyen L |veditors=Coddet C |url=https://books.google.com/books?id=o-wz5phUzhEC&pg=PA117 |title=Plasma Sprayed Self-lubricating Cr203-CaF2 Coatings: Friction and Wear Properties |book-title=Thermal Spray: Meeting the Challenges of the 21st Century; Proceedings |conference=15th International Thermal Spray Conference |date=25–29 May 1998 |location=Nice, France |volume=1 |pages=117–122 |doi=10.1361/cp1998itsc0117 |isbn=0-87170-659-8}}

Vos F, Delaey L, De Bonte M, Froyen L (25–29 May 1998). "Plasma Sprayed Self-lubricating Cr203-CaF2 Coatings: Friction and Wear Properties". In Coddet C (ed.). Thermal Spray: Meeting the Challenges of the 21st Century; Proceedings. 15th International Thermal Spray Conference. Vol. 1. Nice, France. pp. 117–122. doi:10.1361/cp1998itsc0117. ISBN 0-87170-659-8.

I have tweaked the sandbox to allow |volume= in non-periodical {{cite conference}} templates.

—Trappist the monk (talk) 12:01, 16 October 2016 (UTC)

Volumes not showing up in {{cite thesis}}

Hey guys, I just noticed that the "volume" part of {{cite thesis}} isn't working. I wonder if a recent change might have knocked it out.

• Smith, John (1999). All about Frogs (PhD thesis). Vol. Vol. 1. {{cite thesis}}: |volume= has extra text (help)
• Smith, John (1999). All about Frogs (PhD thesis). Vol. Vol. 2. {{cite thesis}}: |volume= has extra text (help)

See? The first one should show "Vol. 1" and the second should show "Vol. 2".--Brianann MacAmhlaidh (talk) 01:12, 16 October 2016 (UTC)

Assuming the documentation is correct and volume should be supported by thesis, I investigated the code. This is happening because in Module:Citation/CS1/Configuration templates_using_volume does not include 'thesis' in the set of templates that should use the volume parameter. The full list is {'citation', 'audio-visual', 'book', 'conference', 'encyclopaedia', 'interview', 'journal', 'magazine', 'map', 'news', 'report', 'tech report'}. Presumably it should be {'citation', 'audio-visual', 'book', 'conference', 'encyclopaedia', 'interview', 'journal', 'magazine', 'map', 'news', 'report', 'tech report', 'thesis'}. I've added it to the sandbox configuration. The sandbox configuration outputs the following...

• Smith, John (1999). All about Frogs (PhD thesis). Vol. Vol. 1. {{cite thesis}}: |volume= has extra text (help)
• Smith, John (1999). All about Frogs (PhD thesis). Vol. Vol. 2. {{cite thesis}}: |volume= has extra text (help)

...which appears to fix the issue when using the sandbox version. Does the above look OK to you? —RP88 ^(talk) 02:02, 16 October 2016 (UTC)

Yeah, that works. But is this just a complaint about the documentation? Instead of these contrived examples, is there a real-life need for this change? The operation of |volume= and |issue= were adjusted at the time of this conversation. So that it's easy to find, I've added the table from that conversation to Help:Citation Style 1#Pages.

—Trappist the monk (talk) 10:24, 16 October 2016 (UTC)

Are you directing this question to me? I don't know the circumstances surrounding why the original poster brought up this issue, but yes, multi-volume theses are not uncommon. See, for example, page 11 of Cornell's Thesis and Dissertation Guide or page 6 of Princeton's Doctor of Philosophy Dissertation And Master's Thesis Submission Requirements. —RP88 ^(talk) 12:27, 16 October 2016 (UTC)

Yep, multivolumed dissertations exist out in the wild. In many cases they're appendixes and whatnot. The thing is that I've cited a few on Wikipedia and have only now noticed the numbers weren't showing up. So I was hoping for a fix. RP88, your tweak looks good to me. Would there be any problem implementing it? --Brianann MacAmhlaidh (talk) 00:31, 17 October 2016 (UTC)

Brianann MacAmhlaidh, I don't anticipate any issues with my change since my edit to Module:Citation/CS1/Configuration/sandbox was very minor. If my change is not reverted, my change should be active the next time an admin updates the live version with the version from the sandbox. It has been a few months since the last update, but it looks like a discussion is taking place above about deploying the version in the sandbox very soon. —RP88 ^(talk) 02:40, 17 October 2016 (UTC)

OK, thanks RP88.--Brianann MacAmhlaidh (talk) 23:52, 17 October 2016 (UTC)

biorXiv error handling

Following Headbomb's creation of the error tracking category, I've added a check for biorXiv ids (checking that the id is a number).

• Doe, J. "Title". bioRxiv hey. {{cite journal}}: Check |biorxiv= value (help); Cite journal requires |journal= (help)

− Pintoch (talk) 11:26, 18 October 2016 (UTC)

• Doe, J. "Title". bioRxiv 1234567. {{cite journal}}: Check |biorxiv= value (help); Cite journal requires |journal= (help)
• Doe, J. "Title". bioRxiv 12345. {{cite journal}}: Check |biorxiv= value (help); Cite journal requires |journal= (help)
• Doe, J. "Title". bioRxiv 123456. {{cite journal}}: Check |biorxiv= value (help); Cite journal requires |journal= (help)

The first two should give error messages as well. Headbomb {talk / contribs / physics / books} 11:37, 18 October 2016 (UTC)

Why so? I don't know anything about these ids, for me they are just numbers. If you know of any better regular expression, feel free to update the sandbox with it. − Pintoch (talk) 11:54, 18 October 2016 (UTC)

The bioRxiv id, as currently implemented, has exactly six digits (legitimate values currently range from 000067 to 081646). They've exhausted about 8% of their scheme in the 3 years they've been operating, so it is unlikely they'll be forced to increase the size of the bioRxiv id anytime soon. I've updated the bioRxiv check in Module:Citation/CS1/Identifiers/sandbox to report an error if the id is anything other than exactly six digits. —RP88 ^(talk) 12:49, 18 October 2016 (UTC)

We do not restate the erroneous value when invalid ids are detected. I tried to remove it in the sandbox and didn't get it quite right. I have reverted my change since I have to run off and don't have time to debug right now. – Jonesey95 (talk) 14:40, 18 October 2016 (UTC)

It should work now. − Pintoch (talk) 14:50, 18 October 2016 (UTC)

Looks better. Thanks. – Jonesey95 (talk) 17:04, 18 October 2016 (UTC)

|title= and |work= are not synonyms in Template:Cite book

{{cite book |last=Thompson |first=Richard |date=2008 |work=Willamette Valley Railways |pages=29, 32, 59 and 77 |publisher=[[Arcadia Publishing]] |isbn=978-0-7385-5601-7}}

produces:

Thompson, Richard (2008). Arcadia Publishing. pp. 29, 32, 59 and 77. ISBN 978-0-7385-5601-7. {{cite book}}: |work= ignored (help); Missing or empty |title= (help)

I'm a little surprised by this. --Izno (talk) 12:22, 19 October 2016 (UTC)

Why? I don't see why you would expect |work= and |title= to be aliases. Peter coxhead (talk) 13:29, 19 October 2016 (UTC)

I wonder if these design flaws should have their own section in the "documentation" so that people don't keep asking the same questions about them. I vaguely remember discussions about this stretching back years. This particular one (about the ambiguous function/definition of |title=) keeps coming back, perhaps because it is a flaw that can be easily seen by editors. 65.88.88.126 (talk) 13:51, 19 October 2016 (UTC)

I've just been musing on the ambiguity problem this morning as I reported this, but I didn't want to make this particular un-expectation about the larger issue. --Izno (talk) 14:06, 19 October 2016 (UTC)

@Peter coxhead: Is a book not a work? Is the title of the book not reflect of the title of the work? |work= is aliased in several other locations (|website=, and I believe |journal= and |encyclopedia=) that would indicate that these should be aliases. --Izno (talk) 14:06, 19 October 2016 (UTC)

Precisely. |work= is aliased to entities that need titles as well, so if it were aliased to |title= it would be confusing. Some cases would need |title= and |work=, in other cases they would be duplicates. Peter coxhead (talk) 15:25, 19 October 2016 (UTC)

@Peter coxhead: Then |title= is also inconsistent--sometimes being used for minor work items (a chapter, section, or a webpage) and sometimes major work items (a book). --Izno (talk) 11:19, 20 October 2016 (UTC)

|title= is not used for a chapter or a section. The only real "level" inconsistency I can see is that, by tradition, "title" is used for a journal article, which is in some ways like a chapter of a volume of a book (since it's a contribution to a volume of a journal). Webpages are a different matter altogether: citation styles were created before the web, and web cites have had to be shoehorned into existing protocols. It probably would have been better to use different parameters for purely web-based sites (as opposed to otherwise published material hosted on the web), but we are where we are. Peter coxhead (talk) 12:36, 20 October 2016 (UTC)

The specific concern is about the use of parameters in CS1 templates, not how their labels are used in general. The ambiguity in the use of |title= stems from a design flaw that allows a parameter ("title") to mean two different things, depending on the {{cite xxx}} used: e.g. in {{cite journal}} it refers to a fragment in a source; in {{cite book}} it refers to the source in toto. However, the source is actually represented by |work= in the so-called design of CS1 templates; so this cascades into another dependency that seems out of joint: why are some labels for "work" (e.g. "journal") aliases of "work", and some (e.g. "title" in {{cite book}}) aren't? This brings up even more inconsistencies, but enough of that. As noted, this argument is perennial. 72.43.99.146 (talk) 13:18, 20 October 2016 (UTC)

I don't regard it as a "design" flaw; it reflects pre-existing usage in citation terminology, which is historical rather than entirely logical. Peter coxhead (talk) 22:31, 21 October 2016 (UTC)

This "historical" use, which is irrelevant in a newer system targeted to non-experts, is what led to a flaw in design, where system-wide parameters assume different functionality. It's obvious in the code. More so in application, where it results in confusion. 24.193.13.108 (talk) 01:06, 22 October 2016 (UTC)

Documentation of {{cite AV media}} should not refer to "text of the publication"

In {{Cite AV media/doc}}, the documentation of the URL parameter refers repeatedly and inappropriately to "the online location where the text of the publication can be found". AxelBoldt (talk) 02:38, 20 October 2016 (UTC)

@AxelBoldt: Are you suggesting that AV media probably isn't in text form? :D WP:BOLD applies. --Izno (talk) 11:18, 20 October 2016 (UTC)

I've updated the centralized documentation of the URL parameter at Template:Citation_Style_documentation/url to add a 'media' option that causes the doc to use 'media' in place of 'text of publication'.and then added the option to the URL section at Template:Cite AV media/doc. —RP88 ^(talk) 12:22, 20 October 2016 (UTC)

Perfect, thank you! AxelBoldt (talk) 17:48, 20 October 2016 (UTC)

doi-broken-date / dead-url behaviour tweak

Now I get that in a sense, it makes sense to disable a link if it doesn't work:

• {{cite journal |author=Smith, J. |year=2006 |title=Article of Things |url=http://example.com |journal=Journal of Important Stuff |volume=5 |issue=2 |page=23 |doi=10.1023/123456 |doi-broken-date=2016-10-20}}
• Smith, J. (2006). "Article of Things". Journal of Important Stuff. 5 (2): 23. doi:10.1023/123456 (inactive 2016-10-20).{{cite journal}}: CS1 maint: DOI inactive as of October 2016 (link)

However, NOT having the link makes it really annoying to verify if the DOI is still inactive (many of those flaggings are done by Citation bot when the doi resolver is down or is having some hiccups. And this is very inconsistent with how we treat dead urls, where we keep the link, but don't even flag them!

• {{cite journal |author=Smith, J. |year=2006 |title=Article of Things |url=http://example.com |journal=Journal of Important Stuff |volume=5 |issue=2 |page=23 |doi=10.1023/123456 |dead-url=yes}}
• Smith, J. (2006). "Article of Things". Journal of Important Stuff. 5 (2): 23. doi:10.1023/123456. {{cite journal}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

What we should really have is something like

• Smith, J. (2006). "Article of Things". Journal of Important Stuff. 5 (2): 23. doi:10.1023/123456.^{[dead doi]}
• Smith, J. (2006). "Article of Things". Journal of Important Stuff. 5 (2): 23. doi:10.1023/123456.

With |dead-url= changed to support dates, with the templates invoking {{dead link}} and {{dead doi}} (which would need to be created) and passing the date to those templates so they can populate the relevant cleanup categories. Or implement some equivalent function.Headbomb {talk / contribs / physics / books} 15:09, 20 October 2016 (UTC)

Link to a free pdf, e.g. via Springer Sharedit, in cite?

The paper [3] is available for free in pdf format at [4] via an "author-access-token" as part of the Springer Nature Sharedit. That is, you can't get to the free pdf via the normal Nature url, but you can get directly to it via the sharedit link, which Springer says can be "posted anywhere". It seems to me we'd like to include both the regular Nature link and the sharedit link as part of a cite, but I don't see any clean way to do that now. Am I missing something, or should we add this somehow to the cite journal template? ★NealMcB★ (talk) 21:27, 20 October 2016 (UTC)

Use |doi=10.1038/nature20101 and |url=http://...

"Hybrid computing using a neural network with dynamic external memory". doi:10.1038/nature20101. {{cite journal}}: Cite journal requires |journal= (help)

—Trappist the monk (talk) 21:56, 20 October 2016 (UTC)

May I ask, why should the non-free link be added when a free one is available? Or am I missing something? 65.88.88.75 (talk) 22:04, 20 October 2016 (UTC)

It's generally useful to provide identifiers (especially DOIs). If readers want to import the citation in their citation manager (for instance Zotero), it makes it easier. − Pintoch (talk) 22:15, 20 October 2016 (UTC)

It also makes template maintenance much easier, as bots can make use of identifiers in ways they can't do with URLs. Likewise if you print the article, the DOIs (and other links) make it much easier to find the article than typing a very cumbersome URL like http://www.nature.com/articles/nature20101.epdf?author_access_token=ImTXBI8aWbYxYQ51Plys8NRgN0jAjWel9jnR3ZoTv0MggmpDmwljGswxVdeocYSurJ3hxupzWuRNeGvvXnoO8o4jTJcnAyhGuZzXJ1GEaD-Z7E6X_a9R-xqJ9TfJWBqz for those who have access to academic subscription and the like. Headbomb {talk / contribs / physics / books} 22:20, 20 October 2016 (UTC)

Amazing. Not a single word about what these templates are actually for: to apply a consistent citation style as an aid to the reader so that s/he can easily verify an article. How many readers import citations to citation managers? How many are interested in template maintenance and bots? How many would rather have the simplest, most direct way to verify the cited claim? Or is it that there are unlimited development resources so that these trivial tangents (vis-a-vis the stated goals of verification) are equal in importance to producing stable, easy-to-use code without bugs? 71.125.43.126 (talk) 12:53, 21 October 2016 (UTC)

Amazing? Hardly. That wasn't the question asked. Headbomb {talk / contribs / physics / books} 13:05, 21 October 2016 (UTC)

Forgetting about the technical details, having a DOI is also interesting for human readers as a witness that the paper has been peer-reviewed and published, unless the DOI has a particular shape (such as the ones issued by figshare). It is not designed for that, but as far as I can tell it does play that role in some communities. If I see a citation with only title, authors and link, I don't know what to expect. Maybe clicking on the link would give me that information, but I find it useful to have it in Wikipedia already. − Pintoch (talk) 13:58, 21 October 2016 (UTC)

DOIs are also much less likely to change or degrade over time. URLs come and go like the weather. – Jonesey95 (talk) 17:08, 21 October 2016 (UTC)

CO2 markup in cite templates

I have read at Template:Citation § COinS that one should not include HTML or wiki markup in cite templates, such as {{cite book}}, as these contaminate the COinS metadata embedded in Wikipedia pages. That includes everything: ''x'' for italics and   for non-breaking spaces.

I searched this archive and found several threads on this topic.

It seems that there are exceptions and that the COinS extraction code is somewhat intelligent. I am particularly interested in "CO₂" in titles. It seems clumsy to have to revert to "CO2". To record CO₂ in a title, can one use CO<sub>2</sub> or {{co2}}? Surely the HTML tags will be stripped out before creating the metadata? What happens with {{co2}}? Or should one prioritize typesetting in a Wikipedia article (and use such markup) over the COinS metadata (which perhaps wants only clean text)? Any guidance would be helpful. Best wishes. RobbieIanMorrison (talk) 20:17, 21 October 2016 (UTC)

Getting the title correct should take precedence over encoding metadata that nobody actually uses. If the title as published is CO₂, it would be incorrect to write it as CO2 and we should not do that, no matter how loudly the cOiNs proponents might scream. On the other hand, if there is a CoInS-compliant way of marking it up that also produces the correct appearance, then that would be preferable to other markups that have the same appearance but are harder to generate correct metadata for. The same issues come up, by the way, in mathematics papers with formulas in their titles, or for that matter with book reviews that contain the italicized title of the book they are reviewing. —David Eppstein (talk) 21:08, 21 October 2016 (UTC)

Stripping html markup from the value assigned to |title= and other title-holding parameters has been on my todo list for a while. Until recent changes to MediaWiki broke it, the module did a fair job of stripping <math>...</math> markup from titles for use in the metadata. Now, those metadata with equations in their titles may have a recognizable equation or they may have a stripmarker, which to those who consume citations via the metadata is completely meaningless. The module has, for quite awhile, stripped off standard bold and italic apostrophe markup from |title=, |script-title=, |chapter=, and |script-chapter= (and aliases) so that the markup causes correctly rendered titles but the metatdata are not contaminated.

Alas, other things have been more important and real life is currently interfering.

—Trappist the monk (talk) 21:55, 21 October 2016 (UTC)