Help talk:Citation Style 1

Template:NewMusicBox

Resolved

Would anyone care to make {{NewMusicBox}} a wrapper for a suitable CS1 template? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:56, 26 July 2016 (UTC)

Doesn't this question first belong on that template's talk page? Or, in lieu of that, a notice to the template's author about the conversation here?

—Trappist the monk (talk) 09:59, 28 July 2016 (UTC)

No. It needs someone with an understanding (better than mine, or I would do it) of CS1. This is the place where such people congregate. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:41, 31 July 2016 (UTC)

@Pigsonthewing: I've made {{NewMusicBox/sandbox}}, which is a wrapper for {{Cite interview}}. Note that if this sandbox version is used, someone should go through the articles using this template and change the parameter |composer=[[Composer article|Composer]] (or |composer=[[Composer]]) to |composer=Composer|composer-link=Composer article - Evad37 [talk] 06:07, 1 August 2016 (UTC)

@Evad37: Thank you. I've asked for an AWB operator to assist. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:43, 30 August 2016 (UTC)

All done, now. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:40, 20 September 2016 (UTC)

Cite interview title and italics

I searched in the CS1 archives regarding {{cite interview}} and couldn't find a reason for why cite interview italicizes its title.

I couldn't find anything in our Manual regarding the title of an interview. MLA and Chicago recommend (not official links!) to place the title of a published interview in quotation marks, while APA doesn't seem to have a recommendation (presumably because they consider published interviews to take the format of the publication type in question--official blog from 2009--APA then seemed to have the practice of italicizing their titles regardless, so maybe it's not worth considering).

Would there be support for changing how interview titles are cited to use quotation marks instead of italics? (I did note Help talk:Citation Style 1/Archive 5#The "title" parameter in the Cite interview, which seems to work around a local issue and which happens to use the italics as a feature, not a bug, but as cite interview is only used about 3k times, I doubt that we couldn't fix them locally as necessary.) --Izno (talk) 22:46, 27 August 2016 (UTC)

Yeah, should be quotation marks. The major work in which the interview is published gets the italics.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:14, 28 August 2016 (UTC)

{{cite interview}} is one of those templates that needs a rewrite. To make it work with {{citation/core}}, |program=, |callsign=, and |city= are all concatenated into the meta-parameter ID. For some reason, |type=, which is media descriptor, is used to modify |interviewer(s)= (an alias of |others=). When I converted the template to use Module:Citation/CS1, I retained these peculiarities because the task at the time was to faithfully reproduce {{citation/core}}.

—Trappist the monk (talk) 11:09, 2 September 2016 (UTC)

I'm happy to have a discussion actually about remapping/rewriting for cite interview, but I suspect the change needed for |title= would be simple.

Regarding the other stuff in your comment, the template talk page's history may be an interesting view into template's history and may explain some of the peculiarities.

• Type looks to be explained: it looks like the name just overlaps and so cleanup is needed for it. We might want to do a survey (add a category) of the pages using type in cite interview.
• Program should probably alias |work=; usage seems to indicate that the field might need some cleanup.

City should probably map to |location= or |publication-place=. |callsign= mapping to ID doesn't seem like a bad choice, but it shouldn't override ID in case another is identified. In our current example at Template:Cite interview, the call sign seems to be an alias for the |publisher= or possibly the republisher, as in the second example (which would go in |via=). NPR for some reason is the program, which doesn't make sense to me. Maybe call-sign should wait for another day. :D

Another personal peculiarity: I find the mapping of interviewee to author peculiar, but not interviewer to author--ostensibly, they should share credit, because the interviewer thought of and published the questions asked. Of course, now we have |contributor=, if we don't think the interviewer should share credit... just some thoughts.

To get around the issue in the H:CS1 archive, I might suggest the following order regarding the URL: title, work/program, and if neither are available (unlikely--the interview may as well be unpublished at that point!) the text "interview with interviewer" should probably get the url. Of course, |work= can usually take a wikilink, so I'm not sure about that suggestion... So many cut out linking work, and simply: if title is missing, then link the text "interview with" or possibly "interview". --Izno (talk) 11:41, 2 September 2016 (UTC)

This search suggests that there aren't too many {{cite interview}} templates that use |type=.

In looking through that list, I notice stuff like this ('video' and the 'Interview' static text in separate parentheses – because there is no |interviewer=):

{{cite interview |subject= Sia|subjectlink= Sia Furler|type= video|title= Sia—Interview|url= http://www.bbc.co.uk/later/artists/sia/|program= ''[[Later... with Jools Holland]]''|callsign= BBC Two|city= London|date= October 2008 |accessdate=14 November 2008 }}

Sia (October 2008). "Sia—Interview" (video). Retrieved 14 November 2008. {{cite interview}}: Unknown parameter |callsign= ignored (help); Unknown parameter |city= ignored (|location= suggested) (help); Unknown parameter |program= ignored (help); Unknown parameter |subjectlink= ignored (|subject-link= suggested) (help)

So that needs fixing.

Remapping |program= → |work= seems obvious as does |city= → |location=. |callsign= → |publisher=?

I wonder if we shouldn't treat interviewers the same way we treat translators: create enumerated |interviewern=, etc; have dedicated static text so instead of Translated by $1 we use Interviewed by $1; |type= if set overrides the predefined meta-parameter TitleType value (just like all of the other cs1 templates that use predefined TitleType).

Titles are required for all cs1|2 templates. I'm not sure we should break that rule here.

—Trappist the monk (talk) 13:36, 2 September 2016 (UTC)

The template currently supports |interviewer= and |interviewers=. I don't see a problem with adding the enumerated case, and perhaps interviewer-first/last; would the intent be to add that to the metadata as I suggested? Otherwise, doesn't seem worth it.

I'm wondering if we can't just remove the non-standard parameters; namely, |call-?sign= (179 articles), |city= (465 articles), and |program= (563 articles).

Should we choose not to remove them:

• For callsign, it looks like it's subject to the standard work/publisher confusion, but indicating perhaps a higher-level work. I don't think capturing the higher-level work is necessary or desirable, so setting it to publisher would be okay in the majority of cases.
• I think we're agreed re city and program.

Regarding titles, don't we have a keyword lying around when the title is unknown or is not present for the lesser work in question? It's not documented in the generic documentation, if so. --Izno (talk) 16:08, 2 September 2016 (UTC)

For the sake of consistency, interviewer names would have the same parameter variants ans other namelists.

The only names in the metadata are author names. Translators, editors, interviewers, others, coauthors; none of these get into the metadata. When the metadata standard changes or we adopt another standard, then those names can be included.

We should deprecate before we remove, but I am in favor of removing those three parameters.

Only {{cite journal}} allows |title=none because there is an abbreviated 'style' used in some scientific disciplines that omits article titles in journal citations.

—Trappist the monk (talk) 11:04, 3 September 2016 (UTC)

The only point in response, because I'm fine with the rest: the handful of links above for the other styles each noted the case of the untitled interview. I'm personally fine with an interview being untitled and having an error, but it seems to me like the other information present would be sufficient (namely, the combination of interviewer, interviewee, and work). Maybe it should be questionable from our point of view whether the interview is legitimately published if it contains no title. *shrug* I think the other changes clearly have my agreement. :D --Izno (talk) 23:12, 3 September 2016 (UTC)

I've marked the parameters callsign, program, and city as deprecated in the sandbox and provided replacement documentation in the errors page. The below should provide at least one error:

Cite interview comparison

Wikitext	{{cite interview|program=Program|sandbox=yes|title=Title}}
Live	"Title" (Interview). {{cite interview}}: Unknown parameter |program= ignored (help); Unknown parameter |sandbox= ignored (help)
Sandbox	"Title" (Interview). {{cite interview}}: Unknown parameter |program= ignored (help); Unknown parameter |sandbox= ignored (help)

Cite interview comparison

Wikitext	{{cite interview|callsign=Callsign|sandbox=yes|title=Title}}
Live	"Title" (Interview). {{cite interview}}: Unknown parameter |callsign= ignored (help); Unknown parameter |sandbox= ignored (help)
Sandbox	"Title" (Interview). {{cite interview}}: Unknown parameter |callsign= ignored (help); Unknown parameter |sandbox= ignored (help)

Cite interview comparison

Wikitext	{{cite interview|call-sign=Call-sign|sandbox=yes|title=Title}}
Live	"Title" (Interview). {{cite interview}}: Unknown parameter |call-sign= ignored (help); Unknown parameter |sandbox= ignored (help)
Sandbox	"Title" (Interview). {{cite interview}}: Unknown parameter |call-sign= ignored (help); Unknown parameter |sandbox= ignored (help)

Cite interview comparison

Wikitext	{{cite interview|city=City|sandbox=yes|title=Title}}
Live	"Title" (Interview). {{cite interview}}: Unknown parameter |city= ignored (|location= suggested) (help); Unknown parameter |sandbox= ignored (help)
Sandbox	"Title" (Interview). {{cite interview}}: Unknown parameter |city= ignored (|location= suggested) (help); Unknown parameter |sandbox= ignored (help)

Cite interview comparison

Wikitext	{{cite interview|callsign=Callsign|city=City|program=Program|sandbox=yes|title=Title}}
Live	"Title" (Interview). {{cite interview}}: Unknown parameter |callsign= ignored (help); Unknown parameter |city= ignored (|location= suggested) (help); Unknown parameter |program= ignored (help); Unknown parameter |sandbox= ignored (help)
Sandbox	"Title" (Interview). {{cite interview}}: Unknown parameter |callsign= ignored (help); Unknown parameter |city= ignored (|location= suggested) (help); Unknown parameter |program= ignored (help); Unknown parameter |sandbox= ignored (help)

I'm boggled on where to go in the module to correct the use of italics versus quotation. I'd like a pointer and then to see if I can implement it myself. --Izno (talk) 04:37, 17 September 2016 (UTC)

Okay, I've figured out the title change. I made a decision to 'prefer' some values; I'm not hung up on a change in that regard. I will look at the type next. --Izno (talk) 05:38, 17 September 2016 (UTC)

I tweaked the remapping of parameters a bit. When a variable is set, no need to re-set it. Carry on.

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

I went to implement a "fix", but maybe we should discuss how we want the citation to appear instead in the following cases:

1. |type= is set and |interviewer= (or variant) is set.
2. |type= is set and |interviewer= is not set.
3. |type= is not set and |interviewer= is set.
4. |type= is not set and |interviewer= is not set.

--Izno (talk) 16:19, 17 September 2016 (UTC)

I think that I would like to see |type= default to |type=Interview regardless of the presence or absence of |interviewer=. That way is consistent with other cs1 templates that have default |type= values. If an editor chooses, |type= may be set to something other than the default value.

Along with that, perhaps |interviewer= is treated the same way we treat |translator=; fixed text as prefix: 'Interviewed by <interviewer-name-list>' (or some such).

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

Should interviewers come before or after translators? --Izno (talk) 15:07, 18 September 2016 (UTC)

I've started implementing interviewers and it looks like i broke something with title type = interview; I will be back later. --Izno (talk) 15:10, 18 September 2016 (UTC)

I took care of some stray punctuation. In doing so, I made two assumptions: interviewers should be available to every citationClass/mode, and they should come before translators. These can be changed if someone wants. --Izno (talk) 20:49, 18 September 2016 (UTC)

Type and language

When |type= and |language= are both specified where a title appears (and perhaps without a title?) (as with any of the citation templates that default a type), we get output that looks like

Subject. "Title" (Interview) (in French). Publisher.

We should also clean this up after. --Izno (talk) 15:46, 18 September 2016 (UTC)

This also occurs with |type= and |format=:

Subject. "Title" (Format) (in French). Publisher.

And all three:

Subject. "Title" (Format) (Interview) (in French). Publisher.

With work included, these become:

• Subject. "Title". Work (Interview) (in French). Publisher.
• Subject. "Title" (Format). Work (in French). Publisher.
• Subject. "Title" (Format). Work (Interview) (in French). Publisher.

--Izno (talk) 20:49, 18 September 2016 (UTC)

When we updated {{cite map}} last year to put it on the Lua module, we gave it a little bit of "intelligence" that I think should be put into play in other situations. For example:

• "Map" (Format) (Map). Atlas. Scale (in French). Publisher.

In this case, the map title is followed by the type indication instead of listing it after the title of the encompassing work, which itself isn't a map. In the future, I'd do something like:

• "Map" (Map, Format). Atlas (in French). Scale. Publisher.

which would merge the adjacent parenthetical statements together and shift the language away from the scale so as not to imply that the scale itself was in another language. Imzadi 1979 → 00:13, 19 September 2016 (UTC)

local tcommon

to

else	-- all other CS1 templates
	tcommon = safe_join( {Title, TitleNote, Conference, Periodical, Format, TitleType, Series, Language, 
		Volume, Others, Edition, Publisher, Agency}, sepc );
end

we have a whole bunch of "stuff these together" while for e.g. Language regarding styling we have:

if is_set (Language) then
	Language = language_parameter (Language);	-- format, categories, name from ISO639-1, etc
else
	Language="";					-- language not specified so make sure this is an empty string;
end

Language is getting stuff done to it that doesn't care about the other things that might be parenthetically placed in that location. TitleType is similar. For these two, which are referenced only rarely elsewhere in the module, fixing this issue may be trivial, I think. Format on the other hand seems to be referenced in multiple different locations and will likely require a bit more hacking. Mostly this is research on my part. :D --Izno (talk) 04:09, 22 September 2016 (UTC)

Type expectations

To return to a previously (as in years ago) requested modification/clarification, what exactly is |type= supposed to be? Is it:

1. Type of medium ("video" "print" "audio" "digital" "plaque" "photograph" etc.)
2. Type of source ("interview" "media notes" "thesis" "press release" etc.)
3. Type of binding/packaging ("paperback" "CD" "VHS" or in digital bindings, "file-format"/"platform and file-format" etc.)
4. Whatever

Please do not repeat here what type: states in the various template docs, it's painful. Assuming that no. 4 above does not apply, can a less confusing |type= be had? 65.88.88.127 (talk) 19:47, 19 September 2016 (UTC)

Citation/"source" type is what the phrase is used for those citation classes which use the type by default, and this is echoed by the documentation in Help:CS1. It seems to me that the medium/source/packaging question is something of a false trichotomy--all of those may be source types; while I might prefer to see something like "video interview" when someone uses |type=, I wouldn't be bothered by just seeing |type=[Vv]ideo. --Izno (talk) 13:56, 21 September 2016 (UTC)

By the same logic, all {{cite xxx}} templates are unneeded specializations of {{citation}}. For citation purposes, i.e. to expeditiously direct people to proof of claims in an article, "medium" is not a "source", and neither of the two is "binding". 72.43.99.146 (talk) 15:00, 21 September 2016 (UTC)

Unwanted semicolon

When a book or article has more than one article or editor, with Template:Cite book a semicolon is placed between the first and second author, or between the first and second editor. For example "Dominic Baker-Smith; Cedric Charles Barfoot". I think this should be a comma. In the ISBD, a semicolon is used when contributors to a publication have different roles, which are mentioned in the description, for examples an editor, author, illustrator or translator. A comma or the word 'and' are usually used however between contributors with the same role (like two authors). In most referencing styles I see elsewhere, like APA style, the same applies. Bever (talk) 21:20, 1 September 2016 (UTC)

CS1 follows the "Last, First" convention for most names. Comma separators between contributors would not work well with the current scheme. There is also some facility for indicating roles in CS1 already. Is there any specific reason for CS1 to comply with ISBD? 65.88.88.127 (talk) 21:33, 1 September 2016 (UTC)

@Bever: you can include |last-author-amp=yes which inserts an ampersand between the last two authors (or editors) in a list. In your example, you'd get "Dominic Baker-Smith & Cedric Charles Barfoot". If you used |first=Dominic |last=Baker-Smith |first2=Cedric Charles |last2=Barfoot, you'd get "Baker-Smith, Dominic; Barefoot, Cedric Charles", which makes clear why we use the semicolon without the optional parameter to use an ampersand between the last two entries in an author list. Imzadi 1979 → 01:55, 2 September 2016 (UTC)

I can the point you both make about confusing commas. In scientific publications, often only initials are used for first names, so they are easily recognizable, making the extra commas less problematic. Sometimes the comma between last name and initials is even omitted. Personally I think the reversed name order is only useful when you want to sort the publications alphabetically (on last name), which is typically not the case when using footnotes... Bever (talk) 16:47, 18 September 2016 (UTC) PS Thank you for the ampersand advice.

Alterations in separators based on whether the first name is an initial or not seem like a non-starter to me. As for the sorting comment, list of full citations are (correctly) sorted by Last where WP:SFN and WP:GENREF is employed. 65.88.88.127 (talk) 18:51, 18 September 2016 (UTC)

Cite Polish law

I've made {{Cite Polish law}} a wrapper for {{Cite web}}, but it has |volume= and |number= parameters, which I've temporarily shoe-horned into the |website= parameter. Is there a better solution? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:58, 7 September 2016 (UTC)

I've solved that by making it wrap {{Citation}}, instead. Please let me know if my edits can be improved further. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:09, 7 September 2016 (UTC)

A technicality, but AFAIK, {{citation}} is Citation Style 2, not CS1, so your wrapper template is not quite accurate. Keep up the bold work. – Jonesey95 (talk) 13:59, 7 September 2016 (UTC)

Why not use cite journal instead of cite web? Headbomb {talk / contribs / physics / books} 15:01, 7 September 2016 (UTC)

Someone has reverted your changes but left the documentation inconsistent. Before I realised that I created a sandbox and testcases to experiment with using the mode parameter, but so far that has not worked as I expected. I've not touched the live template. --Mirokado (talk) 22:00, 7 September 2016 (UTC)

Thank you, all. I've made it wrap {{Cite journal}}, instead. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:31, 8 September 2016 (UTC)

I've been reverted, again, apparently because the template did not match "the legal Polish format". I wasn't aware that we were subject to Polish law. It would be interesting to review the internal consistency of citations in articles using the template. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:03, 13 September 2016 (UTC)

Language template

A side issue: I understand now why this revert of part of my edit was made, but how else can we show the language of a non-English title? (As opposed to the |language= of the target page.) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:11, 8 September 2016 (UTC)

We've discussed a |title-lang=es/|title-es= in the past, derived from discussion at the feature request for it. Aside: I doubt there would be support for displaying the language of the title, as that's really just fluff for a citation. --Izno (talk) 12:32, 8 September 2016 (UTC)

It's not about displaying the language of the title (my use of "show" was imprecise, sorry), but marking it up correctly. For instance, {{lang|pl|Twoje zdrowie!}} displays as Twoje zdrowie! and emits the HTML: <span xml:lang="pl" lang="pl">Twoje zdrowie!</span> . Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:10, 8 September 2016 (UTC)

Then you may want to review the archive discussion; contributors do desire this function, but were a) split on the parameter set and b) per the Html 5 specification, specifying only the lang and not the xml:lang e.g. <span lang="pl">Twoje zdrowie!</span>. --Izno (talk) 19:50, 8 September 2016 (UTC)

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 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:

Category:TEMPORARY Cite newspaper The Times using 'column' parameter – 1,287

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)

Improving HTML citation element semantics

Cite

Given the following wiki markup as example:

{{Cite web |url=https://support.apple.com/en-us/HT202944 |title=TCP and UDP ports used by Apple software products |date=2014-11-08 |website=Apple Support |publication-date=2016-02-05 |archive-url=https://web.archive.org/web/20160913023842/https://support.apple.com/en-us/HT202944 |archive-date=2016-09-13 |dead-url=no |access-date=2016-09-13}}

produces output similar to this:

<cite class="citation web"><a rel="nofollow" class="external text" href="https://support.apple.com/en-us/HT202944">"TCP and UDP ports used by Apple software products"</a>. <i>Apple Support</i> (published 2016-02-05). 2014-11-08. <a rel="nofollow" class="external text" href="https://web.archive.org/web/20160913023842/https://support.apple.com/en-us/HT202944">Archived</a> from the original on 2016-09-13<span class="reference-accessdate">. Retrieved <span class="nowrap">2016-09-13</span></span>.</cite>

My concern is that the HTML citation element (<cite>) is wrapped around the whole template. The WHATWG HTML Standard says in section 4.5.6 that A person's name is not the title of a work and and the element must therefore not be used to mark up people's names. Further examples are given in that section for correct usage according to that specification. HTML5 specification published by W3C (which was developed by WHATWG, but later diverged by W3C) allows using a name as a citation, but I believe the examples given mostly point at the direction of giving a very specific citation based on work name (in our case, |title=).

The correct output should look something like this (untested, I mind you):

<p class="citation web"><a rel="nofollow" class="external text" href="https://support.apple.com/en-us/HT202944">"<cite>TCP and UDP ports used by Apple software products</cite>"</a>. <i>Apple Support</i> (published 2016-02-05). 2014-11-08. <a rel="nofollow" class="external text" href="https://web.archive.org/web/20160913023842/https://support.apple.com/en-us/HT202944">Archived</a> from the original on 2016-09-13<span class="reference-accessdate">. Retrieved <span class="nowrap">2016-09-13</span></p>.

Time

It may be a good idea to change the <span> for dates to <time> element as well, for further improving the semantics. I also question if the quotation marks " need to be around the <cite> element, as if they are only for visual appearance then they should be added in CSS.

My view is biased towards WHATWG as the current status of HTML as the right thing to do, because updating to the WHATWG specification would satisfy requirements of both W3C's HTML5 and WHATWG's HTML standard. The current template does not allow satisfying HTML standard requirements.

References

Not quite so relevant citations

Hickson, Ian. "The cite element". In Pieters, Simon; van Kesteren, Anne; Jägenstedt, Philip; Denicola, Denicola; et al. (eds.). HTML Standard. Acknowledgements. (Living Standard ed.). WHATWG. 4.5.6. Archived from the original on 13 September 2016. Retrieved 13 September 2016. {{cite book}}: External link in |others= (help); Unknown parameter |dead-url= ignored (|url-status= suggested) (help) Hickson, Ian. "Is this HTML5?". In Pieters, Simon; van Kesteren, Anne; Jägenstedt, Philip; Denicola, Denicola; et al. (eds.). HTML Standard. Acknowledgements. (Living Standard ed.). WHATWG. 1.2. Archived from the original on 13 September 2016. Retrieved 13 September 2016. {{cite book}}: External link in |others= (help); Unknown parameter |dead-url= ignored (|url-status= suggested) (help) Sheppy; Sebastianz; JohnnyWalker; Jeremie; openjck; et al., eds. (7 August 2006). "<cite>". HTML element reference. Mozilla Developer Network. Mozilla (published 2 May 2016). Archived from the original on 13 September 2016. Retrieved 13 September 2016. {{cite encyclopedia}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)CS1 maint: numeric names: editors list (link) Hickson, Ian; Berjon, Robin; Faulkner, Steve; Leithead, Travis; Navara, Erika Doyle; O'Connor, Edward; Pfeiffer, Silvia, eds. (28 October 2014). "The cite element". HTML5 (W3C Recommendation ed.). W3C. 4.5.6. Archived from the original on 13 September 2016. Retrieved 13 September 2016. {{cite book}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

80.221.159.67 (talk) 11:50, 13 September 2016 (UTC)

Discussion

We changed cite deliberately to use cite per Help_talk:Citation_Style_1/Archive_8#HTML5 bait-and-switch: The cite element again. Please review that discussion. --Izno (talk) 12:40, 13 September 2016 (UTC)

And the discussion linked therein at MediaWiki_talk:Common.css/Archive_17#The_cite_element_needs_to_not_auto-italicize_any_longer. --Izno (talk) 12:43, 13 September 2016 (UTC)

And finally, the actual implementation discussion at Help_talk:Citation_Style_1/Archive_9#<cite> has been fixed, so we can now use it for entire citation. --Izno (talk) 12:46, 13 September 2016 (UTC)

Regarding the styling (issue with quotation marks), we have already defaulted the use of cite to not-italicize based on the issue that sometimes the citation provides only work vice work and sub-section title. Long works use italics while sub-work-level usually use quotation marks. So I believe there would not be consensus (even if it made sense to change our use of cite, which it doesn't) to change those points of styling in CSS. No comment regarding the use of the time element. --Izno (talk) 12:57, 13 September 2016 (UTC)

Time discussion

The point about <time> seems well made. Can we do that? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:44, 16 September 2016 (UTC)

Reading up on the spec for the time element, we would need to be careful with this, such that the datetime= attribute is both supplied and valid (it expects all-numeric dates), for example <time datetime=2016-09-16>16 September 2016</time>. If we don't validate that attribute, it would need to be omitted, and the enclosed date would then need to be all-numeric, i.e. <time>2016-09-16</time> would be valid, but <time>16 September 2016</time> would not. --Redrose64 (talk) 20:19, 16 September 2016 (UTC)

I would be concerned about adding a such tag for a non-Gregorian date given that the input is ISO8601-like and thus does not provide for calendar model. But any date after 1923 should certainly get it. The dates aren't technically all-numeric, for sub-date information, but that's mostly a non-issue.

I would apply this to all dates in the citation templates. --Izno (talk) 20:29, 16 September 2016 (UTC)

According to https://www.w3.org/TR/html5/infrastructure.html#dates-and-times "To unambiguously identify a moment in time prior to the introduction of the Gregorian calendar (insofar as moments in time before the formation of UTC can be unambiguously identified), the date has to be first converted to the Gregorian calendar from the calendar in use at the time (e.g. from the Julian calendar). The date of Nero's birth is the 15th of December 37, in the Julian Calendar, which is the 13th of December 37 in the proleptic Gregorian calendar." Wikipedia uses the date that appears on the publication itself, which may very well be non-Gregorian. So either we forget about this <time> thing altogether, or we have to examine the date to see if it is a plausible Gregorian date (rather than, say, an Islamic calendar) and then make sure it is no earlier than 1923. Jc3s5h (talk) 20:37, 16 September 2016 (UTC)

I think we can start with a limited rollout for all dates after 1923 since this will be the vast majority of dates anyway, unless there's some calendar in use presently which had years greater than 1923 in the Gregorian year 1923. --Izno (talk) 20:49, 16 September 2016 (UTC)

I would think the first test is to see if the entire date string can be successfully parsed as a machine readable date. I imagine "Summer 2015" would fail this, even though it is a valid Wikipedia publication date. This should also screen out dates that have some notation of a non-Gregorian calendar, something like "Japanese year 2015". Then check if the year is greater than 1923 and not ridiculously far in the future. If you try too hard to extract a date from a bunch of junk, you are likely to find out that what you treated as junk was actually a warning that the date doesn't mean what you think it means. Jc3s5h (talk) 21:27, 16 September 2016 (UTC)

phab:T34545 is still open, but its parent task phab:T25932 says the tag is implemented. Looks like Danny B noticed that on the child task and asked the question awhile ago without answer. My browser seems to think that the tags emitted above are supported in the wikitext, so I'll probably go close the child. --Izno (talk) 20:49, 16 September 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)

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 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)

Un-deprecate |version=

Back in 2015, the decision was made to deprecate |version= for {{cite arxiv}}. This should not have been done. The main reason against deprecation is that the majority of arxiv links with v1/v2 etc. are more or less mindlessly copy-pasted, and the person giving the link didn't mean to link to a specific version. |version= gave us the means to distinguish between the intentional linking to a specific version of a preprint, vs the accidental linking which really should just be the most up to date version of the preprint. So please restore |version= in {{cite arxiv}}. Additionally, the v1/v2 of the arxiv identifier should be hidden when people write {{cite xxx|arxiv=1001.1002v2}}. Headbomb (talk) 00:40, 18 September 2016 (UTC)

Why does that distinguishing need to happen? The deliberate user will still use the version of interest, while the ignorant user will use the version which provided him the information (which will presumably be the latest version, as you note). WP:SAYWHEREYOUGOTIT protects us regardless. --Izno (talk) 02:54, 18 September 2016 (UTC)

WP:SAYWHEREYOUGOTIT says that you should cite the version where you found the information in question, so mindless copying and pasting of the version that the editor has actually read is exactly what we want. If an editor cites version 2 and then version 3 (the latest version) changes radically to stop supporting the statement in question, omitting the version number is the wrong thing to do. |version= is redundant to |arxiv= (or its alias, |eprint=), since "v2" or whatever can easily be included in the identifier. – Jonesey95 (talk) 04:07, 18 September 2016 (UTC)

Yes, but a statement should always be backed by the latest version, and if it isn't then we should tag it with {{fails verification}} / remove the statement. That's why an explicit |version=2 means you really DID mean the second version, because the 3rd version (or later) no longer supports that fact. Likewise, the v2 of the arxiv identifier of a {{cite journal}} should be stripped because in that case the arxiv link is a convenience link, and should always link to the most up to date version. Headbomb {talk / contribs / physics / books} 10:44, 18 September 2016 (UTC)

Simplify (these guidelines)

I want to reference a YouTube video (yes I've checked notability copyright etc). This is surely a common if not one of the primary online references today? Anyway, to do this I have to take an UG course in wiki editing. The HowTo text here is a technical manual and the examples are really fragmented. Is there not a simple way to demonstrate the FULL basic use of the template and then go into detail rather than the taxonomic tree hierarchy approach that seems to be being adopted. Demonstrating the elementary use of the template is not so helpful as it only serves to encourage the poor use of the template. It's a balance. IMO this time it's way out of kilter. I'd rewrite it myself but .... maybe when I have your expertise? ;) LookingGlass (talk) 11:07, 19 September 2016 (UTC)

{frustrated} well I was shocked .. answer is that I was helpfully redirected from Template talk:Cite AV media. More chaos and dumb machineness from the redirect and merge junkies. Grrr! Help pages? The clue's in the name! LookingGlass (talk) 11:11, 19 September 2016 (UTC)

No, the clue is in the big banner at the top of this page, which says "To help centralise discussions and keep related topics together, the talk pages for all Citation Style 1 templates and modules redirect here.". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:16, 19 September 2016 (UTC)

@LookingGlass: I concur; it is quite helpful to discuss things that impact the various templates in a single place, and it gives us one page to watch to help instead of following a few dozen talk pages.

Now, to try to help answer your question, if you want to cite a video uploaded to YouTube, use the {{cite AV media}} template. Ignore for a moment that the video is on that website. Cite the author(s)/creator(s) of the video, the publication date, the title of the video, the original publisher, etc. Add |type=Video so that readers know it is a video. Include the URL to the video, and then at the very end, I would add |access-date=September 19, 2016 and |via=YouTube. This lets people where and when you accessed the video file without crediting YouTube as the original publisher, just as we wouldn't credit Google Books as the original publisher of a scanned copy of a book they merely host online. Imzadi 1979 → 13:17, 19 September 2016 (UTC)

@Imzadi1979: Thanks for your reply, though my experience is that that a central page is not very helpful. See Staggeringly unhelpful, below. I solved the issue of the citation. As with all wikipedia editing it is very easy - once you find the code needed - doing that though takes a great deal of time. The question then arises "why am I doing this?" - why spend all this time on editing when the cognoscenti don't try to make things simple?

Bottom line: there is a line of text in the template documentation that sets out the parameters of the "template" (this label ie unhelpful I find - what we are addressing is actually a line of code) but this template description is incomplete (e.g the Via parameter is omited). The primary problem though is that descriptions of the parameters are sometimes provided in curly quotes sometimes not sometimes with sub-parameters sometimes not sometimes describing sub-parameters but not as such sometimes with curly quotes etc etc you get the point I hope. The curly quotes are a red herring. They do not form part of the "template". I would have edited the template/doumentation to clarify but .... And I would have had this discussion on that template there is the chance had been afforded. As it is anyone befuddle by similar issues is sent here and the conversation grows exponentially.

The mistake being made with the template documentation is one in my experience typically found in text written by technical experts to serve as documentation for their own subject. There is a natural tendency to assume those not familiar with our own area of expertise are simple minded. Perhaps consequently we fail to recognize fundamental semantic errors in our text, let alone more complex ones. Simply put this issue, pandemic in wiki, is driven by succumbing to the sweet temnptation of hubris - a flaw I have in abundance! Thanks again.

LookingGlass (talk) 13:35, 21 September 2016 (UTC)

Your comments regarding poor documentation would not be the first. WP:BOLD applies. :D --Izno (talk) 13:53, 21 September 2016 (UTC)

Long article titles

Do we truncate long old-timey headlines (called titles in the template) down to the first sentence? "title= Vernon Castle Dies In Airplane Fall. Killed at Fort Worth Avoiding Collision That Threatened Lives of Three. Won Captaincy At Front. Numerous Deaths In Training Call Attention to the Need of Skilled Inspectors. Castle's Spectacular Feats. Skilled Inspectors Needed. Vernon Castle's Career. Starred on the Stage" --Richard Arthur Norton (1958- ) (talk) 23:06, 19 September 2016 (UTC)

That kinda seems like a inline TOC. Do you have the original copy of that article somewhere so we can review it? Headbomb {talk / contribs / physics / books} 23:13, 19 September 2016 (UTC)

After searching, it really does look like that's the full title. I'd quote it in full personally, but if someone only kept it to 'Vernon Castle Dies In Airplane Fall' I wouldn't revert either. Headbomb {talk / contribs / physics / books} 23:20, 19 September 2016 (UTC)

We've run into something similar citing specific older laws in California that made changes to the state's highway system. In those cases, we used only the first X words/Y characters and truncated the titles. Another example comes from citing social media postings. Since they lack a separate headline, most style guides use the text of the posting or tweet as the title, and they advise truncating overly long items, usually to a 40-word incipit. Imzadi 1979 → 23:29, 19 September 2016 (UTC)

Chicago Manual of Style (14th ed., p. 15.115) agrees with shortening titles of old works with excessively long titles. Jc3s5h (talk) 00:06, 20 September 2016 (UTC)

Sounds like the titles of Papal Bulls - typically truncated to the first two or three words. --Redrose64 (talk) 12:30, 20 September 2016 (UTC)

For English literature from about the 16th century (e.g. Shakespeare) up until somewhere in the 18th century (e.g. Johnson) the style was to use big ponderous titles that double as a sales pitch. This looks really awkward to modern readers who are used the sales pitch being rendered devoit of actual meaning and condensed down into three to five words (in big ponderous fonts and high-contrast colours, usually accompanied by an overproduced cover design). However, these are actually the titles of the works, and any shortening edges into WP:OR territory (mostly won't matter at all, but it demands care). I think the guidance in the context of citation templates should be to use the full title (however awkward it may look to modern readers), and that any abbreviation needs careful consideration. If the resulting issues (which, again, mainly boil down to dissonance for readers unused to the long titles) are considered severe enough, the place to try to address it would be at the MoS, where additional guidance (such as: abbreviations should be supported by reliable sources, and explained in text; or whatever) can be included that would be somewhat out of scope for the CS1 context. And personally, I would advocate weak guidance to use full titles but to leave room for individual editors' judgement and local consensus for an article (and, where applicable, WikiProject).

But to give a counter-example: Shakespeare's plays have short to medium length titles (e.g. A most pleasant and excellent conceited comedy, of Sir John Falstaffe, and the merry wiues of Windsor.) which have effectively universally agreed shortened titles that our reliable sources use (and often also discuss directly); to wit: The Merry Wives of Windsor. For these there is very little sense in using the ponderous title in the citations (in the text it needs to be discussed, but for different reasons). Shakespeare also provides the counter-counter-example: since the modern short names are later abbreviations, there is some times actual scholarly discussion over which part of the long title should form the short title (to construct an example on the fly: should it be Merry Wives or Sir John Falstaff? There are actual examples of this that I can't be arsed to dig up right now, incidentally.) Picking a particular short title can (and I stress, can, not will) end up privileging the position of The Oxford Shakespeare over the Arden Shakespeare in violation of WP:NPOV (WP:DUE). --Xover (talk) 09:48, 21 September 2016 (UTC)

• You can almost write a whole biography from just the article title. I suppose you can use the first sentence in the title and the rest add to the quote= section. That way you do not end up with a sea of blue. --Richard Arthur Norton (1958- ) (talk) 01:24, 20 September 2016 (UTC)

End time parameter

There exists a "time" parameter for this template, but it is used only to denote the start time. Is there nothing to denote the end time? Kailash29792 (talk) 12:14, 20 September 2016 (UTC)

Not specifically. The time parameters are |minutes=, |time= and |time-caption=. The output rendering for |minutes= is fixed:

Title. 4:30 minutes in.

as is the plain |time=:

Title. Event occurs at 4:30.

but the |time= rendering can be overridden with |time-caption=:

{{cite av media |title=Title |time=4:30 and 4:45 |time-caption=Between}}

Title. Between 4:30 and 4:45.

or:

{{cite av media |title=Title |time=4:45 |time-caption=Ends at}}

Title. Ends at 4:45.

—Trappist the monk (talk) 09:31, 21 September 2016 (UTC)

For segments of a longer video; would not |start-time= combined with either |duration= xor |end-time= make sense? It appears intuitively so to me, but I hadn't really thought about it. --Xover (talk) 09:53, 21 September 2016 (UTC)

Staggeringly unhelpfull

With an arrogance all too customary of wikipedia, User:Huntster reverted my edit without troubling even to notify me. (thanks robot?) The Edit summary given (I should be thankful for small mercies) said simply:

keep discussion on the centralised page. Explanation has been given there.  

Truly sublime! Currently that/this page runs to over 26,000 words. There are 23 pages shown of its archive.

This is the comment that s/he reverted on the redirect's Talk page:

== WHY?!?!?! ==
I want to raise an issue with this page.  So wt* is the purpose of a redirect to a general Talk page that covers ...... ALL the citation1 pages ?!?!?!?!!!  Words fail. Sincerely. If you need more explanation I can't imagine any could ever suffice. LookingGlass (talk) 11:15, 19 September 2016 (UTC)

Irony^2 ??

Needless (?) to say (see above) I am not watching this page, but, if relevant .. address me? Thanks. I haven't troubled Hunster with this, again, for reasons that should be self-explanatory (to anyone who stumbles across this message in a bottle).

LookingGlass (talk) 13:06, 21 September 2016 (UTC)

As the above notice indicates, and to which you have been pointed prior by Pigsonthewing: To help centralise discussions and keep related topics together, the talk pages for all Citation Style 1 templates and modules redirect here. A list of those talk pages and their historical archives can be found at Help talk:Citation Style 1/Centralized discussions. It seems quite self-explanatory why you were reverted as a result. If you would like to change the practice of centralizing these talk pages, you should start a discussion, since you have been reverted. Be forewarned that I doubt anyone else will support your position in a change request discussion. --Izno (talk) 13:43, 21 September 2016 (UTC)

LookingGlass, adding text to a redirect page will always be reverted if it is noticed. – Jonesey95 (talk) 14:30, 21 September 2016 (UTC)

Thanks Jonesey95 (and Izno), the sublime pointlessness of attempting to engage with wiki's Kafkaesque controllers doesn't escape me, yet nonetheless sometimes I succumb. Dialogues of the deaf. Messages in bottles. Peace out LookingGlass (talk) 18:49, 27 September 2016 (UTC)

Date format flexibility or error message suppression in Cite templates

More flexibility in the date parameter of {{cite}} templates is needed. See David Biespiel as of 18:22, 22 September 2016, which includes a reference to a two-week issue of The New Yorker, entered as:

• {{cite magazine |title=Want to understand the jihadis? Read their poetry. |author=Robyn Creswell |author2=Bernard Haykel |magazine=The New Yorker |date=June 8 & 15, 2015 |url=http://www.newyorker.com/magazine/2015/06/08/battle-lines-jihad-creswell-and-haykel}}

which displays with a spurious date error message:

• Robyn Creswell; Bernard Haykel (June 8 & 15, 2015). "Want to understand the jihadis? Read their poetry". The New Yorker. {{cite magazine}}: Check date values in: |date= (help)

The New Yorker web page says that the article appeared in the "June 8 & 15, 2015 Issue", so the date is correct. There should be a way of suppressing the error message. — Anomalocaris (talk) 23:27, 22 September 2016 (UTC)

The New Yorker just has to be different, don't they? You could put that information in |issue= as a workaround, with |date=2015 as a placeholder for the date. Or you could just call it June 8, 2015, which is what they do in their own URL: the URL for the article contains the string "/2015/06/08/", not "/2015/06/08&15/" – this is a tip-off that they know they are just being precious. – Jonesey95 (talk) 03:44, 23 September 2016 (UTC)

Closed ranges are allowed in |date=, so you could use "June 8–15, 2015":

• Robyn Creswell; Bernard Haykel (June 8–15, 2015). "Want to understand the jihadis? Read their poetry". The New Yorker.

Not quite right, I know, but possibly acceptable. Peter coxhead (talk) 09:51, 23 September 2016 (UTC)

Jonesey's suggestion renders like so, for comparison:

Robyn Creswell; Bernard Haykel (2015). "Want to understand the jihadis? Read their poetry". The New Yorker. No. June 8 & 15, 2015.

Not much better. Edition might also work:

Robyn Creswell; Bernard Haykel (2015). "Want to understand the jihadis? Read their poetry". The New Yorker (June 8 & 15, 2015 ed.).

--Izno (talk) 12:44, 23 September 2016 (UTC)

Maybe a new parameter could tell the module to output a different character separate a date range, e.g. |date=June 8–15, 2015|range-symbol=& – so an ampersand could be displayed for the above above, or a / could be used when the source uses it (as in "June/July") - Evad37 [talk] 14:41, 23 September 2016 (UTC)

I don't think that is needed. The double issue can be uniquely identified by the date of publication, which is June 8, 2016. This is when it became generally available, and that is sufficient for purposes of discovery. To remove any doubts or to be completist, |issue= can also be used; however that is not imo strictly needed for verification. I usually do this:

Robyn Creswell; Bernard Haykel (June 8, 2016). "Want to understand the jihadis? Read their poetry". The New Yorker. No. [n1–n2] (double issue).

72.43.99.138 (talk) 16:19, 23 September 2016 (UTC)

To add, if the issue numbers are not available, the mysterious everyman-parameter |type= can be used:

Robyn Creswell; Bernard Haykel (June 8–15, 2016). "Want to understand the jihadis? Read their poetry". The New Yorker (double issue).

72.43.99.138 (talk) 16:25, 23 September 2016 (UTC)

To reply to Evad37 above, but "June/July" would not be in keeping with our MOS, and it should be switched to an en dash. That's the sort of minimal change traditionally allowed. We don't have to faithfully copy every exact detail from a source into a citation. Imzadi 1979 → 20:59, 23 September 2016 (UTC)

Various workarounds have been suggested, but none of them recognize the fundamental issue. Sometimes articles are published in parts, with each part in a separate issue. It's possible, but less common, for the parts to not be in consecutive issues. So just it is possible to list pages as 18–9, 25, 36–9, it should be possible to list several publication dates. Jc3s5h (talk) 19:56, 23 September 2016 (UTC)

In the case of articles that are part of multi-part series published periodically, I would cite each part of the series as a separate article instead of trying to collapse them into a single citation. The overall title of the series can be noted in |department=. Imzadi 1979 → 20:56, 23 September 2016 (UTC)

@Jc3s5h: That would be way too cumbersome, as a single citation would have to denote: several dates, several issue numbers, and several page numbers. This is hampering discovery of the source and verification of the cited claims. One citation per issue, please. If the parameter |series= is available then it could be set as |series=part x [of y] or similar. Then all the related citations can occupy a sublist within the "References" listing. 184.75.21.30 (talk) 23:45, 23 September 2016 (UTC)

CiteSeerX support

It's been discussed all over the place, but I can't find any effort to actually implement it. We should have add the |citeseerx= parameter giving

• |citeseerx=10.1.1.220.7880 → CiteSeerX: 10.1.1.220.7880

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

This edit was made; while I am agreeable to the lower-cased version, I could find nothing to indicate that CiteSeerX is every uppercased in its entirety. I would possibly support |CiteSeerX=. --Izno (talk) 19:05, 23 September 2016 (UTC)

Parameters are traditionally all lowercase, but they display 'normally', hence why |arxiv=1001.1234 yields arXiv:1001.1234. I suppose we could do |citeseerx=10.1.1.220.7880 → CiteSeer^X: 10.1.1.220.7880, but I've got no strong feelings here. Headbomb {talk / contribs / physics / books} 19:13, 23 September 2016 (UTC)

Oh, you're referring to the parameter name itself? There's been some movement to support ALLCAPS version of those for a while. It's annoying, but I guess this is just consistency with the other parameters. Headbomb {talk / contribs / physics / books} 19:17, 23 September 2016 (UTC)

It should work now.

• Simpson, Alex (2012). "Measure, Randomness and Sublocales". Annals of Pure and Applied Logic. 163 (11): 1642–1659. CiteSeerX 10.1.1.220.7880. doi:10.1016/j.apal.2011.12.014.

Let me add support for |CiteSeerX=. − Pintoch (talk) 19:46, 23 September 2016 (UTC)

All caps for not-all-caps identifiers

Hum, actually |arXiv= is not supported, and it seems to me that identifiers tend to be lowercase or ALLCAPS only, so maybe it would be better to keep only |citeseerx= and |CITESEERX= for uniformity. − Pintoch (talk) 19:49, 23 September 2016 (UTC)

The parameters with all caps variants are only all caps because they are abbreviations. CiteSeerX is not. I suppose CSX is, but does that occur in the wild? --Izno (talk) 21:48, 23 September 2016 (UTC)

I have removed CITESEERX (leaving citeseerx) from the Whitelist sandbox page because the name is not an initialism or acronym. DOI, ISBN, and others are allowed in all caps because they are initialisms or acronyms. – Jonesey95 (talk) 05:33, 24 September 2016 (UTC)

The caps are there for pretty much all identifiers though, even those that aren't initialisms or acronyms (e.g. |ARXIV=, |BIBCODE=), etc... I've restored it for consistency with the current behaviour. We should, however, add |arXiv=/|bioRxiv=/|CiteSeerX=. Headbomb {talk / contribs / physics / books} 06:40, 24 September 2016 (UTC)

When adding or removing parameters, don't forget to update both the configuration and whitelist. − Pintoch (talk) 07:28, 24 September 2016 (UTC)

So, consistency is not necessarily desirable here. Even if it were, let's talk about having all-caps versions of identifiers which are never used as acronyms. You point out that there are presently identifiers which shouldn't be all caps, because they aren't so outside Wikipedia I presume. As it happens, BIBCODE isn't used in the wiki-wild. I haven't checked the others, but we should deprecate that. --Izno (talk) 15:04, 24 September 2016 (UTC)

ARXIV is used some 1k times, but almost all of those are empty. Let's deprecate that also. It looks to me like ARXIV is being trans-wikied from somewhere, probably German Wikipedia. --Izno (talk) 15:06, 24 September 2016 (UTC)

I'm fine with deprecating those, but right now the sandbox is inconsistent in its logic, and that is not acceptable. Either update the sandbox version to deprecate those parameter names, or allow |CITESEERX=, but a bastardized version shouldn't be there. The caps versions should be likely replaced by |arXiv=/|bioRxiv=/|CiteSeerX=.

That being said, if the germans use all caps versions like ARXIV and CITESEERX, we should keep ours too for compatibility.Headbomb {talk / contribs / physics / books} 15:12, 24 September 2016 (UTC)

Most of the ones I saw from German were using {{citation/core}}, which was odd; it's probable that if we updated our module, we'd be fine on any transwiki points. Even if we weren't, we can add a property suggestion for those all-caps variants. Do we want to replace those all-caps versions with the properly-capitalized versions? You seem to want that. --Izno (talk) 15:27, 24 September 2016 (UTC)

All caps should be reserved for parameters that are pure initialisms, like |DOI= and |ISBN=. I recommend removing support for |BIBCODE=. I am fine with supporting mixed caps for parameters whose canonical versions use mixed caps, like |arXiv=/|bioRxiv=/|CiteSeerX=. All parameters should also support pure lower case. – Jonesey95 (talk) 18:04, 24 September 2016 (UTC)

@Izno: I don't get why you keep removing |CITESEERX= from the whitelist. Either we decide to remove capitalized versions of identifiers which are not acronyms, or we decide to keep them. In the former case, there are many other changes to do, for instance |BIORXIV= should also be removed as this parameter will be introduced in the next update of the live module (so, no deprecation needed). In any case, let's try to keep the sandbox in a consistent state, which should ideally reflect a consensus here. And let's not make a mountain out of a molehill, this is about a capitalized version of a parameter in a Wikipedia template… − Pintoch (talk) 12:23, 27 September 2016 (UTC)

I haven't edited in that region since the above date (24 September). No one since has voiced disagreement that we should perhaps deprecate (or remove before release) the all-caps versions of the parameters which are not acronyms, so I was planning to implement that apparent consensus at some point in the near future (today?). Feel free to implement that consensus yourself if you would like. --Izno (talk) 12:26, 27 September 2016 (UTC)

Yeah, I just saw your edits today, so I did not respond earlier. Please go ahead with the rest of the parameters, it would be great to have a consistent sandbox. − Pintoch (talk) 12:43, 27 September 2016 (UTC)

@Headbomb, Pintoch, and Jonesey95: please review configuration edit and whitelist edit. --Izno (talk) 12:58, 27 September 2016 (UTC)

Happy with this, but should we replace the (rare) occurences of |ARXIV= in the wild by |arxiv= before the change is effective? (Could someone with AWB rights do it?) − Pintoch (talk) 13:09, 27 September 2016 (UTC)

Since the parameter is now marked as false, pages including templates with the deprecated parameter will be added to the deprecated parameters category. We should indeed remove the parameter from usage prior to removing the parameter from the whitelist completely, but we do not need to remove the parameter from use prior to release of the changeset. --Izno (talk) 13:16, 27 September 2016 (UTC)

I've seen TTM regularly work on deprecation of attributes in the wild using AWB, so yes, that is possible. --Izno (talk) 13:18, 27 September 2016 (UTC)

At least part of the edit to Module:Citation/CS1/Configuration/sandbox should be reverted. Deprecated parameters should still display as if they weren't deprecated. For example, |coauthor= is deprecated (still) but the module displays its assigned value:

{{cite book/new |author=Author |coauthor=Coauthor |ARXIV=1001.1234 |title=Title}}

Author. Title. {{cite book}}: |author= has generic name (help); Unknown parameter |ARXIV= ignored (|arxiv= suggested) (help)

While not a hill on which I'd care to die, I think that we should avoid mixed case parameter names even to replicate the identifier's canonical name. This is the camel's nose to supporting capitalized parameter names. We deprecated and removed |Author= and a few other similarly capitalized parameters. Let us not return to that.

—Trappist the monk (talk) 13:36, 27 September 2016 (UTC)

I have made the requested edit. I personally would prefer not to have mixed case as well. Aside: Why doesn't coauthor= display an error? --Izno (talk) 13:57, 27 September 2016 (UTC)

If there is more than one deprecated parameter in a template, the module displays an error for the first one it encounters. If I remove |ARCHIVE=, then there is an error for |coauthor=:

Author. Title. {{cite book}}: |author= has generic name (help); Unknown parameter |coauthor= ignored (|author= suggested) (help)

—Trappist the monk (talk) 14:02, 27 September 2016 (UTC)

Yeah, let's not introduce mixed case. − Pintoch (talk) 14:11, 27 September 2016 (UTC)

@Jonesey95 and Headbomb: What do you think about leaving out the mixed-case versions? --Izno (talk) 23:01, 27 September 2016 (UTC)

OK with me. – Jonesey95 (talk) 02:43, 28 September 2016 (UTC)

Well, I don't personally care, and would personally get rid of all caps versions as well. But if the logic is that DOI/ISBN need to stay because some people will use caps for these acronyms instead of doi/isbn, the same argument can be made for mixed cases since some people will use 'correct' casing when writing arXiv/bioRxiv/CiteSeerX/Zbl. So while my personal DGAF levels are fairly high, we do need to think of newbies/user-friendliness... Headbomb {talk / contribs / physics / books} 07:42, 28 September 2016 (UTC)

Casing for compound parameters

Now appears |URL-access= purportedly for consistency. I'm not so sure about that. |URL-access=, if retained, will be the only compound parameter name that has different case on either side of the hyphen. The other 'acronym' compound parameter names, |ignore-isbn-error=, |doi-broken-date=, |dead-url=, etc, are all lower case. I think that compound parameter names should be lower case – which means that we should deprecate |ASIN-TLD= and revert the |URL-access= change.

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

Yet more intrigue. The edit was bold on my part, so I'm not attached to it here. :D --Izno (talk) 12:43, 27 September 2016 (UTC)

I agree with Trappist, I also prefer the fully lowercase version. Otherwise, if we support |URL-access=, we should also support |DOI-access=, |HDL-access= and so on… Let's keep things simple. − Pintoch (talk) 12:50, 27 September 2016 (UTC)

SSRN free access lock

Per #Which identifiers?, we should add the green free access lock to |ssrn= so we can have appended to the SSRN in citations like

• Twomey, A. (2008). "Responsible Government and the Divisibility of the Crown". Public Law (93): 742–767. SSRN 1301166.

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

Done.

• Twomey, A. (2008). "Responsible Government and the Divisibility of the Crown". Public Law (93): 742–767. SSRN 1301166.

− Pintoch (talk) 18:49, 23 September 2016 (UTC)

id-access support

Per #Which identifiers, we should support

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

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)

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)

Intended size (with tooltips)

"Title" / "Title" / "Title"', / "Title" (current/original)

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

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

There. I think we have a winner with alt 1. Colours are there, shackles convey the open-ness, and even if you can't make out the details of the shackle, the amount of filling in the lock's body also conveys that open-ness 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)

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)

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)

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)

ISMN support

We should add |ismn= to support ISMN

• |ismn=979-0-2600-0043-8 → ISMN 979-0-2600-0043-8

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

Already supported:

{{cite book |title=Title |ismn=979-0-2600-0043-8}}

Title. ISMN 979-0-2600-0043-8.

I notice that the rendering has stripped the hyphens. I'll fix that.

—Trappist the monk (talk) 15:22, 23 September 2016 (UTC)

We should update the doc then, because ISMN isn't mentioned. Also, is there a way to auto-hyphen the ISBN/ISMN? That would be really, really nice. Headbomb {talk / contribs / physics / books} 15:49, 23 September 2016 (UTC)

Template:Cite_book#Identifiers, and every other cs1|2 template that uses {{csdoc}}, defines ISMN; has done since this edit. If you are thinking of that abomination TemplateData, perhaps it doesn't. If you want to fix that, go ahead; I will not touch it.

—Trappist the monk (talk) 22:02, 23 September 2016 (UTC)

I was thinking of Help:Citation_Style_1#Identifiers. Never even was aware that Template:Citation Style documentation/id2 even existed, or that Help:Citation_Style_1 didn't make use of it. Headbomb {talk / contribs / physics / books} 22:40, 23 September 2016 (UTC)

The sfn template has a fault when the date is "n.d."

Please see the bug report at Template talk:Sfn#Fault when date is "n.d." Jc3s5h (talk) 15:48, 23 September 2016 (UTC)

For the readers here, the problem has been identified as a feature request to modify Module:Footnotes. The CS1 citations appear to be blameless (this time!). – Jonesey95 (talk) 05:35, 24 September 2016 (UTC)

Template:Cite within nominated for deletion

This TfD discussion could do with input from the citation experts crowd. The question seems to revolve around whether there is a need for a template that formats multiple locations/quotes from within a single source. Uanfala (talk) 14:02, 24 September 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: Category:Pages using citations with url-access and no URL and 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: Category:CS1 errors: url-access without URL and 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)

PMC minor formatting difference when embargoed

I noticed that when a PMC is embargoed, we render a colon after "PMC", but when it is available, there is no colon. I poked through the module code and was unable to find where that happened. Here are examples of {{cite journal}} with no embargo date, an expired embargo date, and a future embargo date.

Author (2006). "Title". Journal. PMC 12345. PMID 123456. {{cite journal}}: |author= has generic name (help)

Author (2006). "Title". Journal. PMC 12345. PMID 123456. {{cite journal}}: |author= has generic name (help); Unknown parameter |embargo= ignored (|pmc-embargo-date= suggested) (help)

Author (2006). "Title". Journal. PMC 12345. PMID 123456. {{cite journal}}: |author= has generic name (help); Unknown parameter |embargo= ignored (|pmc-embargo-date= suggested) (help)

Can someone please find that code and remove the colon from the "future date" example? I'm assuming this will be uncontroversial. Thanks. – Jonesey95 (talk) 22:26, 27 September 2016 (UTC)

it was in Module:Citation/CS1/Identifiers/sandbox:

Author (2006). "Title". Journal. PMC 12345. PMID 123456. {{cite journal}}: |author= has generic name (help); Unknown parameter |embargo= ignored (|pmc-embargo-date= suggested) (help)

—Trappist the monk (talk) 22:41, 27 September 2016 (UTC)

(edit conflict) I think I found it, but I'm about to open a can of worms. It appears to be in Module:Citation/CS1/Configuration/sandbox at "local id_handlers". The can of worms has two parts:

1. Some identifier names (e.g. arXiv and doi) are followed by a colon, and some are not (e.g. PMC and PMID).
2. Identifier capitalization is inconsistent (e.g. ASIN and DOI).

At the risk of having to eat a bunch of worms, I propose removing all colons following identifier names (using nbsp for consistency) and changing "doi" and "hdl" to all caps, per the web sites that "own" these identifiers. – Jonesey95 (talk) 22:46, 27 September 2016 (UTC)

Perhaps not just yet. doi, with the colon preceding the identifier I think is to be lower case. It was originally intended to be like a url scheme if memory serves.

—Trappist the monk (talk) 23:04, 27 September 2016 (UTC)

Yes, I think you are correct. So much for consistency. Thanks for fixing the PMC colon. – Jonesey95 (talk) 02:43, 28 September 2016 (UTC)

This old discussion is related to that. I'm still annoyed that ISBN formatting is different than all others. Headbomb {talk / contribs / physics / books} 07:34, 28 September 2016 (UTC)

The arXiv: formatting, with the colon, is what arXiv uses on its own site to format these things. It is how their identifiers are shown, in pages that list preprints like http://arxiv.org/list/cs.DS/recent, on the abstract page headers for the individual papers, in their recommeded citations, and even embedded into the margin on the first page of the pdfs there. It also is our internal wikilink format (e.g. [[arXiv:YYYY.NNNNN]] does what you might expect it to). —David Eppstein (talk) 07:11, 29 September 2016 (UTC)

Template:Cite DVD notes proposed for merge with Template:Cite AV media notes

This discussion proposes merging Template:Cite DVD notes into Template:Cite AV media notes. Both are existing CS1 templates. Please discuss at the TfD page. – Jonesey95 (talk) 16:47, 28 September 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)