Help talk:Citation Style 1

Citation templates (conception)

Citation templates (reality)

Identifier order messed up.

Why is bibcode displaying before arxiv in?

• "The extended rotation curve and the dark matter halo of M33". Monthly Notices of the Royal Astronomical Society. 311 (2): 441–447. 2000. arXiv:astro-ph/9909252. Bibcode:2000MNRAS.311..441C. doi:10.1046/j.1365-8711.2000.03075.x. {{cite journal}}: Unknown parameter |authors= ignored (help)CS1 maint: unflagged free DOI (link)

Identifiers should be listed in alphabetical order. Headbomb {t · c · p · b} 13:49, 10 June 2017 (UTC)

The identifier labels are sorted with a case sensitive sort. 'B' has an ascii numerical value of 66 (0x42) and 'a' has an ascii numerical value of 97 (0x61). Proof for that is here, where I've added |eissn=1365-2966 and |issn=0035-8711 from the journal's wikipedia article:

"The extended rotation curve and the dark matter halo of M33". Monthly Notices of the Royal Astronomical Society. 311 (2): 441–447. 2000. arXiv:astro-ph/9909252. Bibcode:2000MNRAS.311..441C. doi:10.1046/j.1365-8711.2000.03075.x. eISSN 1365-2966. ISSN 0035-8711. {{cite journal}}: Unknown parameter |authors= ignored (help)CS1 maint: unflagged free DOI (link)

—Trappist the monk (talk) 14:42, 10 June 2017 (UTC)

Well, that ought to be fixed then, either with case-insensitive sorting, or by putting the sortkey in a {{lc:IDENTIFIERNAME}} type of thing. Because it wasn't like that before. Headbomb {t · c · p · b} 15:18, 10 June 2017 (UTC)

There have been no changes to the identifier sorting since at least this version (April 2013) of Module:Citation/CS1.

—Trappist the monk (talk) 15:59, 10 June 2017 (UTC)

I distinctly remember those to be sorted correctly as late as this spring. But even if my memory somehow fails me, those should be sorted alphabetically, regardless of casing. Headbomb {t · c · p · b} 17:02, 10 June 2017 (UTC)

De-archived as unresolved and still in need of a fix. Headbomb {t · c · p · b} 13:32, 22 July 2017 (UTC)

De-archived again. @Trappist the monk and Jonesey95:. Headbomb {t · c · p · b} 13:58, 13 August 2017 (UTC)

Anyone? Headbomb {t · c · p · b} 02:02, 3 October 2017 (UTC)

@Trappist the monk: I see you made good progress on the identifier check below. Any word on identifier sorting? Headbomb {t · c · p · b} 19:48, 27 October 2017 (UTC)

26 July

—Trappist the monk (talk) 19:59, 27 October 2017 (UTC)

Awesome! Can't wait for the next rollout! Headbomb {t · c · p · b} 20:02, 27 October 2017 (UTC)

Any update on doi-broken-date?

If anything, the doi should at the very least still link. Other improvements can wait/get more discussion, but the linking part should be easy to fix. Headbomb {t · c · p · b} 14:25, 11 April 2017 (UTC)

@Trappist the monk: Any way we can get this bundled in the weekend's update? Headbomb {t · c · p · b} 05:29, 26 April 2017 (UTC)

The purpose of this interstitial period is to have a last chance to find and fix bugs; to create or modify supporting documentation, categories, templates, etc. – housekeeping preparatory to the update. It is not the time for new development or new features.

—Trappist the monk (talk) 11:28, 26 April 2017 (UTC)

Yeah well this has been requested a long while ago, is an easy fix, and we have over half a week left. WP:BURO applies here. Headbomb {t · c · p · b} 11:57, 26 April 2017 (UTC)

Can we now implement this? Headbomb {t · c · p · b} 00:27, 2 May 2017 (UTC)

De-archived because discussion is ongoing/unresolved. @Trappist the monk:. Headbomb {t · c · p · b} 17:20, 23 May 2017 (UTC)

@Trappist the monk and Jonesey95: pinging. Headbomb {t · c · p · b} 19:13, 12 June 2017 (UTC)

It makes sense to me to have allegedly broken DOIs linked, since the doi-broken-date is checked by a bot and (a) could have been wrongly applied or (b) could have been a temporary problem or (c) both. There are plenty of links that don't work and are not flagged as such. That's just the state of the web, and always has been. – Jonesey95 (talk) 02:00, 13 June 2017 (UTC)

De-archived as unresolved and still in need of a fix. Headbomb {t · c · p · b} 13:32, 22 July 2017 (UTC)

De-archived again. @Trappist the monk and Jonesey95:. Headbomb {t · c · p · b} 13:58, 13 August 2017 (UTC)

Anyone? Headbomb {t · c · p · b} 02:02, 3 October 2017 (UTC)

@Trappist the monk: any updates on this? I know you did some work related to deprecation, but the doi link should still appear when doi-broken-date is set. Headbomb {t · c · p · b} 13:17, 28 October 2017 (UTC)

Bug when using script-title ISO 639-1 prefix and url-access together?

Hey I think I found a bug that I figured I should point out. Right now the code:

{{cite journal|last1=Wang|first1=Tianqi|last2=Liang|first2=Geqiu|title=Zhōngguó tángláng mù xīn jìlù shǔ jí yī xīn zhǒng jìshù|journal=Acta Scientiarum Naturalium Universitatis Sunyatseni|date=1995|volume=34|issue=2|pages=84–86|script-title=zh:中国螳螂目新记录属及一新种记述|trans-title=New Record of ''Choeradodis'' and One New Species of Mantodea from China|url=http://en.cnki.com.cn/Article_en/CJFDTOTAL-ZSDZ502.014.htm|url-access=subscription|via=[[CNKI]]}}

produces:

Wang, Tianqi; Liang, Geqiu (1995). "Zhōngguó tángláng mù xīn jìlù shǔ jí yī xīn zhǒng jìshù" 中国螳螂目新记录属及一新种记述 [New Record of Choeradodis and One New Species of Mantodea from China]. Acta Scientiarum Naturalium Universitatis Sunyatseni. 34 (2): 84–86 – via CNKI.

Specifically the link reads:

["Zhōngguó tángláng mù xīn jìlù shǔ jí yī xīn zhǒng jìshù" <bdi lang="zh" >中国螳螂目新记录属及一新种记述]

You'll see the <bdi lang="zh" > hanging out in the middle there.

If you remove the url-access or the script-title ISO 639-1 prefix it works, but they don't seem to like each other.

I imagine this is an easy fix so I'd bring it to people's attention. Thanks :)

Umimmak (talk) 11:53, 28 August 2017 (UTC)

Don't have time to look at the code right now, but looks like the culprit could be a missing closing html tag. 72.43.99.138 (talk) 12:39, 28 August 2017 (UTC)

I think it's not an easy fix in the sense that a simple tweak will fix it. The problem lies in the creation of the external link. The code is at Module:Citation/CS1/sandbox (which fixes other problems with the live module's handling of kerning). Editors whined and complained when the access signal wrapped to another line so we tried adding a non-breaking thin space between the end of the link and the access icon. The results of that experiment were disappointing; it did not work. So we opted for adding <span class="nowrap">...</span> around the last word and the icon. The last word is separated from the other words in the label by a space character. If you look at the whole rendering (simplified from the original) you can see that the code found the last space character in the <bdi lang="zh" > tag and inserted the <span class="nowrap"> tag there:

'"`UNIQ--templatestyles-00000026-QINU`"'<cite class="citation journal cs1 cs1-prop-script"><span class="id-lock-subscription" title="Paid subscription required">[http://en.cnki.com.cn/Article_en/CJFDTOTAL-ZSDZ502.014.htm "Zhōngguó tángláng mù xīn jìlù shǔ jí yī xīn zhǒng jìshù" <bdi lang="zh" >中国螳螂目新记录属及一新种记述</bdi>]</span>. ''Acta Scientiarum Naturalium Universitatis Sunyatseni''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Acta+Scientiarum+Naturalium+Universitatis+Sunyatseni&rft.atitle=Zh%C5%8Dnggu%C3%B3+t%C3%A1ngl%C3%A1ng+m%C3%B9+x%C4%ABn+j%C3%ACl%C3%B9+sh%C7%94+j%C3%AD+y%C4%AB+x%C4%ABn+zh%C7%92ng+j%C3%ACsh%C3%B9+%E4%B8%AD%E5%9B%BD%E8%9E%B3%E8%9E%82%E7%9B%AE%E6%96%B0%E8%AE%B0%E5%BD%95%E5%B1%9E%E5%8F%8A%E4%B8%80%E6%96%B0%E7%A7%8D%E8%AE%B0%E8%BF%B0&rft_id=http%3A%2F%2Fen.cnki.com.cn%2FArticle_en%2FCJFDTOTAL-ZSDZ502.014.htm&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

Closing that space doesn't fix the problem because the code will simply find the required space between 'bdi' and 'class'.

The solution to this particular problem is not easy for another reason: interleaving html tags is not permitted. What the code is trying to do is this:

<span class="plainlinks">[http://www.example.com "Transcribed Latin text title" <bdi lang="zh">Original language script <span class="nowrap">title</bdi><span style="padding-left:0.15em">[[File:Lock-red-alt.svg|...]]</span></span>]</span>

MediaWiki will rewrite that and put the closing </bdi> some probably-inappropriate place (especially if |script-title= holds a right-to-left script – Arabic, Hebrew, etc).

Were the language something other than Chinese where there were spaces between words we might do this:

<span class="plainlinks">[http://www.example.com "Transcribed Latin text title" <bdi lang="zh">Original language script</bdi> <span class="nowrap"><bdi lang="zh">title</bdi><span style="padding-left:0.15em">[[File:Lock-red-alt.svg|...]]</span></span>]</span>

Yeah, not so simple and not merely a matter of an omitted tag.

—Trappist the monk (talk) 16:21, 28 August 2017 (UTC)

Why are we not inserting our own closing tags into the proper places, instead of letting Tidy (or whatever) have a guess at it? --Redrose64 🌹 (talk) 16:32, 28 August 2017 (UTC)

We do insert our own closing tags. Nothing that I have written here suggests that we aren't writing complete markup. But, I have said that the markup that we are writing is malformed. It is malformed because of the way the code is written. At the particular place where we assemble the title, the script title, the url and the access signal, the code does not know about <bdi>...</bdi> tags. Because of that for most scripts, English will do here for an example, it places the <span class="nowrap"> between <bdi lang="en"> and </bdi>:

{{cite journal/new |title=Transcription title |journal=Journal |script-title=en:A title in some other script |url=http://www.example.com |url-access=subscription}}

"Transcription title" A title in some other script. Journal. {{cite journal}}: Invalid |script-title=: unknown language code (help)

The output for that looks like this (coloring added and metadata removed for clarity):

<cite class="citation journal"><span class="plainlinks">[http://www.example.com "Transcription title" <bdi lang="en" >A title in some other <span class="nowrap">script</bdi><span style="padding-left:0.15em">[[File:Lock-red-alt.svg|9px|link=|alt=Paid subscription required|Paid subscription required]]</span></span>]</span>. Journal.</cite>

You can see in the above that the tags are interleaved as I described and that closing tags are present.

From this page's source for the example template we get this (coloring added for clarity):

<span class="plainlinks"><a rel="nofollow" class="external text" href="http://www.example.com">"Transcription title" <bdi lang="en">A title in some other <span class="nowrap">script</span><span style="padding-left:0.15em"><img alt="Paid subscription required" src="//upload.wikimedia.org/wikipedia/commons/thumb/c/c8/Lock-red-alt.svg/9px-Lock-red-alt.svg.png" title="Paid subscription required" width="9" height="14" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/c/c8/Lock-red-alt.svg/14px-Lock-red-alt.svg.png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/c/c8/Lock-red-alt.svg/18px-Lock-red-alt.svg.png 2x" data-file-width="512" data-file-height="813" /></span></bdi></a></span>

In the above, mediawiki has closed the <span class="nowrap"> tag prematurely and the <bdi>...</bdi> tags enclose not only the script title but also the lock image markup. This latter might have detrimental effects. Or not; but the markup is still wrong in part because we gave it malformed markup in the first place even though that markup had all of its closing tags.

—Trappist the monk (talk) 17:33, 28 August 2017 (UTC)

Since this seems to require careful code re-write, shouldn't editors be discouraged from using the ISO codes in |script-title= until a solution emerges? There is |language= as an interim fix. (Unless that too presents a problem). 72.43.99.130 (talk) 18:51, 28 August 2017 (UTC)

I don't think so. I suspect that this particular problem is relatively rare. |language= is not a 'fix' because all that it does is categorize the source as a non-English language source and render the language in the final citation.

—Trappist the monk (talk) 09:57, 29 August 2017 (UTC)

That's not it at all. |language= and all other parameters are there to give information to readers about the cited source. In this case, to identify a strange-looking script and provide an important detail about the original source. It is a "fix" only in that sense. The ISO option in |script-title= is a technicality concerning browser rendering. If it breaks the display of the citation for humans. as it does in this case, it has no business there. The focus of CS1 seems hopelessly off. 72.43.99.138 (talk) 14:16, 29 August 2017 (UTC)

Because I do not have a solution to this problem and because I would like to update the live modules, I have removed support for nowrapping url access signal icons. The template at the top of this discussion will now render correctly:

Cite journal comparison

Wikitext	{{cite journal|date=1995|first1=Tianqi|first2=Geqiu|issue=2|journal=Acta Scientiarum Naturalium Universitatis Sunyatseni|last1=Wang|last2=Liang|pages=84–86|script-title=zh:中国螳螂目新记录属及一新种记述|title=Zhōngguó tángláng mù xīn jìlù shǔ jí yī xīn zhǒng jìshù|trans-title=New Record of ''Choeradodis'' and One New Species of Mantodea from China|url-access=subscription|url=http://en.cnki.com.cn/Article_en/CJFDTOTAL-ZSDZ502.014.htm|via=[[CNKI]]|volume=34}}
Live	Wang, Tianqi; Liang, Geqiu (1995). "Zhōngguó tángláng mù xīn jìlù shǔ jí yī xīn zhǒng jìshù" 中国螳螂目新记录属及一新种记述 [New Record of Choeradodis and One New Species of Mantodea from China]. Acta Scientiarum Naturalium Universitatis Sunyatseni. 34 (2): 84–86 – via CNKI.
Sandbox	Wang, Tianqi; Liang, Geqiu (1995). "Zhōngguó tángláng mù xīn jìlù shǔ jí yī xīn zhǒng jìshù" 中国螳螂目新记录属及一新种记述 [New Record of Choeradodis and One New Species of Mantodea from China]. Acta Scientiarum Naturalium Universitatis Sunyatseni. 34 (2): 84–86 – via CNKI.

—Trappist the monk (talk) 12:13, 24 October 2017 (UTC)

This change also removes code that was added to support this issue. With nowrap gone, the additional code became superfluous.

—Trappist the monk (talk) 13:01, 24 October 2017 (UTC)

Parameter for Wikidata ID, redux

User:Headbomb and I suggested a parameter for a work's Wikidata ID; there was support, but discussion has been archived. What's happening about this, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:50, 28 August 2017 (UTC)

I still support this. But how should the link be presented? Wikidata: Q21706380? WD: Q21706380? WDQID: 21706380? Q-ID: 21706380? Something else? Headbomb {t · c · p · b} 17:57, 28 August 2017 (UTC)

One of the first two (if the second, with {{abbr}} or similar), or with a tiny icon. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:49, 28 August 2017 (UTC)

Pigsonthewing (talk · contribs) So I take it we need to declare this via |wikidata=Q21706380. Headbomb {t · c · p · b} 22:09, 28 August 2017 (UTC)

@Headbomb: Yes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:26, 29 August 2017 (UTC)

For my part, I don't see overwhelming support for this. Some support, yes, but also some opposition. When asked how this new parameter would be useful, Editor Pigsonthewing replied, in part: Furthermore, that identifier can in turn be used to fetch identifiers and other metadata for the publication, the author, publisher et al. which seems contrary to the opinion expressed by Editor Headbomb and seconded by Editor J. Johnson: We should most definitely not draw citation data from wikidata.

—Trappist the monk (talk) 11:08, 29 August 2017 (UTC)

I didn't say it would be used to fetch the metadata by the template; but any reader can do so once they know the Wikidata ID; either manually, or by using a tool of their own preference (e.g. this page on Scholia). I don't think either Headbomb (who proposed and supports the addition of the parameter) or J. Johnson objected to that. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:24, 29 August 2017 (UTC)

(EC) Nothing is proposed about drawing information from Wikidata, this would be treated no differently than |doi= or |mr=. Could it be used to fetch stuff from Wikidata? It could, in theory. We might even decide this is desirable in the future. But for now it's simply about given a link to Wikidata, and there was no objection on that. Headbomb {t · c · p · b} 17:26, 29 August 2017 (UTC)

We did have some objections on the simple addition of a new identifier, and I subscribe to Jc3s5h's comments on that. I do not think all unique identifiers are worth displaying to our readers in citations : we should only include well-established bibliographical identifiers that readers will find useful. I suspect many readers would be annoyed to see yet another unique id they do not care about popping up in citations. Just to be clear, I personally love Qids, but I am just not sure this is the right place for them. As a random reader, what does it bring to me? I can click on that identifier, and see a page with the metadata of that citation on a Wikidata. Fine, but I already had the metadata in the citation. Not everybody is a Linked Open Data enthusiast who will experience a warm and fuzzy feeling only at the sight of a Qid… − Pintoch (talk) 19:12, 29 August 2017 (UTC)

The relevant question is "is this useful in relation to the purpose of a citation?" Citations are cluttered already with IDs and potential IDs (review Help:Citation Style 1#Identifiers). I haven't yet seen a strong case in relation to the purpose of a citation, as opposed to information that might be useful to someone. Peter coxhead (talk) 20:59, 29 August 2017 (UTC)

A Wikidata ID might constitute an opportunity to move all of those IDs elsewhere and either a) leave users to investigate themselves or b) pull the identifiers from Wikidata automatically with each invocation (even if you don't want to pull an entire citation from Wikidata). --Izno (talk) 22:08, 29 August 2017 (UTC)

Using a Wikidata ID to replace many of the others might be useful, I agree, although there would need to be discussion on which ones. Peter coxhead (talk) 22:18, 29 August 2017 (UTC)

You ask "As a random reader, what does it bring to me?"; just above your question, I wrote "any reader can do so [fetch identifiers and other metadata for the publication, the author, publisher et al] once they know the Wikidata ID; either manually, or by using a tool of their own preference (e.g. this page on Scholia)". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:03, 29 August 2017 (UTC)

fetch identifiers: CS1/2 already supports loads, the author, publisher et al: that's also easy to include in the citation template, either manually, or by using a tool of their own preference: CS1/2 templates are already inter-operable with many tools thanks to COinS… Again I am playing the devil's advocate here, but I think people are just very likely to reject this change. We should be very careful not to foster the skepticism that already exists around Wikidata among some Wikipedia editors. Changes bringing more Wikidata integration to Wikipedia should bring real value to the community (e.g. better integration in infoboxes) instead of splashing our Wikidata ids all over the place for no apparent benefit. − Pintoch (talk) 06:13, 30 August 2017 (UTC)

CS1/2 already supports loads, the author, publisher et al... What? cs1|2 does not support 'loading' any data from anywhere any other than the template's wikisource. What is it that you really mean?

The opportunity, it seems to me, for integration of cs1|2 and wikidata is best begun by making {{cite Q}} a sterling exemplar of correct use of that resource. Alas, I fear that the opportunity is slipping away. {{cite Q}} could be written to enforce best practices to ensure that the underlying data at wikidata are properly curated. Unfortunately, data deficiencies are being 'fixed' by tweaks to the template code rather than the correct fix to the data source. If {{cite Q}} becomes recognized as a quality tool, then perhaps there is a future for wikidata in cs1|2. But, if slipshod craftsmanship of {{cite Q}} is allowed to continue, I don't hold out much hope for wikidata in cs1|2.

—Trappist the monk (talk) 11:31, 30 August 2017 (UTC)

By already supports loads, I meant "CS1/2 already supports loads of identifiers" (it has support for a lot of identifiers). Sorry about that! − Pintoch (talk) 12:35, 30 August 2017 (UTC)

True, you didn't say it would be used to fetch the metadata by the template but you did not say that the identifier would be a link only; you did not say that the identifier would not be used by the templates to fetch metadata from wikidata. Because this discussion is about modifying cs1|2 to support a wikidata identifier, don't you know that editors might understand your statement to mean: "once implemented, the templates will be able to fetch metadata from wikidata"? Without a statement to the contrary, why shouldn't they draw that conclusion?

—Trappist the monk (talk) 11:08, 30 August 2017 (UTC)

What could the purpose of such a parameter be but to set up future fetches from wikidata? The link itself is not something that would be of much use to readers. —David Eppstein (talk) 12:54, 30 August 2017 (UTC)

Wikidata contains a lot more metadata than what we include in our citations. ORCIDs for authors for instance. We also typically leave out ISSNs, publishers, etc... when citing journal articles. There are lots of benefits beyond data fetching. Headbomb {t · c · p · b} 13:29, 30 August 2017 (UTC)

Sure − so Qids could be useful in COinS, for instance (or even just in wikicode, maybe). But is it really worth displaying that to human readers? − Pintoch (talk) 13:43, 30 August 2017 (UTC)

Yes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:17, 30 August 2017 (UTC)

(edit conflict) Now there's a novel idea: emit all of the identifiers as metadata in COinS, but potentially leave (some of) them out of the displayed version of the citation. Imzadi 1979 → 15:16, 30 August 2017 (UTC)

No, hiding data isn't a novel idea, it's often been suggested, and rejected as harmful, because errors are hidden. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:29, 31 August 2017 (UTC)

For the third time: "any reader can do so [fetch identifiers and other metadata for the publication, the author, publisher et al] once they know the Wikidata ID; either manually, or by using a tool of their own preference (e.g. this page on Scholia)" Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:17, 30 August 2017 (UTC)

Andy, I think we got your point, repeating it verbatim will not make it more convincing. Do you want me to repeat why I think the use cases you are talking about are not useful to the average reader? I can rephrase if that was unclear. But let's avoid being too assertive and have a constructive discussion together! − Pintoch (talk) 16:48, 30 August 2017 (UTC)

Well, if people could stop acting as though no such argument had been presented... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:08, 30 August 2017 (UTC)

Another reason to include Wikidata IDs is that bots can compare what's in the templates to what's on Wikidata, and alert humans to discrepancies. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:29, 31 August 2017 (UTC)

Hmm, again I'm not sure that is very useful: many citations already have some id, so we can compare the metadata in the template and the data associated to that id. In the vast majority of cases, the data that is on Wikidata was created from one of these sources by a tool (such as fatameh), so it's not like we are getting access to a new data source. Granted, in some cases, a human editor might have added some information (such as disambiguating an author), but that seems to be very rare for now. There would also be the possibility to transfer authorlinks from Wikipedia citations to Wikidata items (to disambiguate authors there), but again that is something we can already do based on the existing identifiers. In any case, as you point out, these use cases would be for bots, so I do not see the point of displaying the id to human readers.

Another idea: if Scholia is the tool you want to access from Wikipedia, what about putting directly a link to that tool? Instead of adding something like "WD: Q38197781", it would add "Scholia: Q38197781"?

Anyway, I think there is a simple way to trial your idea and show that the community is not going to reject it. Just create an id template, say {{Scholia}}, along the lines of {{doi}} or {{arXiv}}, and add it to citations in the |id= field:

{{Cite journal| doi = 10.1016/j.genhosppsych.2013.11.007| issn = 0163-8343| volume = 36| issue = 3| pages = 310–317| last1 = Dobscha| first1 = Steven K.| last2 = Denneson| first2 = Lauren M.| last3 = Kovas| first3 = Anne E.| last4 = Corson| first4 = Kathryn| last5 = Helmer| first5 = Drew A.| last6 = Bair| first6 = Matthew J.| title = Primary care clinician responses to positive suicidal ideation risk assessments in veterans of Iraq and Afghanistan| journal = General Hospital Psychiatry| accessdate = 2017-09-01| date = 2014-05-01| url = http://www.sciencedirect.com/science/article/pii/S0163834313003447 | id={{Scholia|Q38197781}} }}

Dobscha, Steven K.; Denneson, Lauren M.; Kovas, Anne E.; Corson, Kathryn; Helmer, Drew A.; Bair, Matthew J. (2014-05-01). "Primary care clinician responses to positive suicidal ideation risk assessments in veterans of Iraq and Afghanistan". General Hospital Psychiatry. 36 (3): 310–317. doi:10.1016/j.genhosppsych.2013.11.007. ISSN 0163-8343. Scholia: Q38197781

If there is wide adoption for this, it will be easy to create the id in CS1/2 and migrate the ids to native parameters. This is what has happened to {{CiteSeerX}}, for instance. CiteSeerX was already used a lot in |id= before it became natively supported, and I migrated the |id={{citeseerx}} to |citeseerx= with a simple regular expression. − Pintoch (talk) 08:11, 1 September 2017 (UTC)

OK, I've knocked something up as {{Scholia}}. It lacks error trapping, which will be needed before widespread use, and I'd probably replace the text "Wikidata" with a tiny icon (and maybe do the same for "Scholia", once an icon is avilable). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:12, 11 September 2017 (UTC)

Please don't display any IDs from unreliable sites (whether Wikidata, Scholia, Quora, Findagrave, or whatever else you can come up with). Cite should be used to link to reliable sources and repositories, not user-generated or otherwise unreliable ones. Fram (talk) 11:51, 11 September 2017 (UTC)

Not in favor per Fram. Ealdgyth - Talk 14:08, 11 September 2017 (UTC)

All citations are user-generated and no more reliable or unreliable than the person who types them in, whether that be on Wikipedia or elsewhere. Making use of a central repository for sources (such as Wikidata) helps keep citations consistent and reduces typos and transcription errors. We should be very much in favour of efforts to stop typing in a hundred versions of the same cite when one is sufficient. --RexxS (talk) 17:20, 13 September 2017 (UTC)

I also support the idea of a parameter like |wikidata= to specify Wikidata nodes. Since these IDs don't have any established meaning outside WP's context, we would not even have to display the numbers in the citations, a small "Wikidata" icon to click on would be enough. Optionally, the ID could be displayed when hovering over the link. And using CSS it should be possible to hide the links depending on user preferences. --Matthiaspaul (talk) 21:15, 24 October 2017 (UTC)

Dragon magazine mess

Dragon has a somewhat nonstandard scheme, whereas it has an issue number, a volume number, a number number, and then pages.

E.g.

• Dobson, Michael (March 1986). "The Forum" Dragon. #107 Vol. 10 no. 10. p. 6.

Now in the wild, this is often cited as

• Dobson, Michael (March 1986). "The Forum". Dragon #107. Vol. 10, no. 10. p. 6.
• Dobson, Michael (March 1986). "The Forum". Dragon #107. 10 (10): 6.
• Dobson, Michael (March 1986), "The Forum", Dragon #107, 10 (10): 6

which has the annoying tendency to put the issue number in the journal field. How do we fix this?

Three options exist, IMO

• Add a hack, so that for |magazine=/|work=/|journal= = The Dragon / Dragon / Dragon Magazine, that we allow both |issue= and |number=
• Add |num-issue=yes, letting the template know that those are distinct fields.
• Shove both issue/number in |issue= or |number=, i.e. |number=3, #111 to create
  • Dobson, Michael (March 1986). "The Forum". Dragon. Vol. 10, no. 10 #107. p. 6.
  • Dobson, Michael (March 1986). "The Forum". Dragon. 10 (10 #107): 6.
  • Dobson, Michael (March 1986), "The Forum", Dragon, 10 (10 #107): 6

What should be done? Headbomb {t · c · p · b} 20:31, 10 September 2017 (UTC)

I'm not a template programmer and don't have a strong opinion on the API. But for Dragon and Dragon+ magazines, looking at bibliographic resources such as DragonDex suggests that the issue number and page are what readers really use when locating articles; volume and number aren't even mentioned. So putting the issue number first, as in your 'in the wild" examples, seems the way to go. As a reader, I'm not bothered by the issue number being in the journal field, but understand for database purposes, it is better to have the issue number as a separate field. --Mark viking (talk) 21:01, 10 September 2017 (UTC)

I agree not one [really] cares about vol/num for Dragon magazine. I suppose we could just purge volume/number from those citation, and do something like

• Dobson, Michael (March 1986). "The Forum". Dragon. No. #107. p. 6.
• Dobson, Michael (March 1986). "The Forum". Dragon (#107): 6.
• Dobson, Michael (March 1986), "The Forum", Dragon (#107): 6

But the output is a bit misleading on some of them (if using {{cite magazine}}). Headbomb {t · c · p · b} 21:21, 10 September 2017 (UTC)

I support the idea of permitting both issue and number as separate parameters when both appear (and with prescribed uses for each). This isn't difficult, and I've encountered many circumstances where this would be useful, even going back to periodicals from the late Victorian era. This would also solve the common problem of issues having designations like "Winter" and "Beatles Commemorative Edition" and whatnot. These could go in |issue=, with |number= used for the number within the |volume=, when both |number= and |issue= are used, but |issue= otherwise being treated as an alias of |number=.

Failing that, I guess one can overload the current number/issue parameter: |volume=XI|issue=3 (Summer). Or, to use the first Dragon example: |volume=10|issue=10 (#107); it just seems a little messy and potentially confusing, even at the source level.
 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:14, 10 September 2017 (UTC)

I also support that idea, and, like you, have run into many examples in the past, where both an issue and a number were given (and variously used in citations, so it isn't a particularly smart idea for us to ignore one of the parameters). However, in the examples I saw, number was used for a running number (typically counting up from the start of the journal), and issue was a number relative to the current volume. I'm open how to render this in the output, but suggest to use # for the number.

--Matthiaspaul (talk) 21:02, 24 October 2017 (UTC)

Quotation language

When the quotation is not in English, should the argument to the quote parameter be in the original language or translated? The title parameter has a trans-title counterpart and so perhaps quote should have a trans-quote equivalent. Stefán Örvar Sigmundsson (talk) 23:56, 25 September 2017 (UTC)

I have always believed that when a quote is important enough to be considered for |quote= it is important enough to have its own end note and that end note cited. So, from that, I would say: quote in the original language and provide a reliably sourced translation in the same end note then cite both. Last time I was paying any attention to the topic of translations, the consensus was that machine translations are not considered reliable. Others will likely disagree with me.

—Trappist the monk (talk) 00:18, 26 September 2017 (UTC)

A long while back someone told me that |quote= was a convenience for providing the exact text of the source that is being paraphrased (here, translated) in the article. I have two problems with that. First, as Trappist says, if it's that important then it should be presented (perhaps even discussed) in the note. (As to "its own end note", I guess you're thinking of the original and the translation. But both sources can be, and should be, handled in the same note. See below.) But quotations of text should not be in the full citation, because that is about the source, not whatever part is being used in the article. In that sense, |quote= is an unuseful parameter, and ought to be deprecated. It derives from this deep confusion and confounding of "note" with "citation".

(In contrast, we do have |trans-title= because a title does identify a source, and either the original foreign language title of an English translation, or an English translation of the foreign language title, is important for identifying a source.)

I think what we agree on is that something like " ... class<ref> {cite|...|quote=Klass}</ref>" is better handled as " ... class<ref> {cite|...} "Klass".</ref>". Or for citing both a translation and the original, where short cites are being used: " ... class<ref>{Harv|Smith|2000|p=84}. "Klass" in the original.{Harv|Ivanoff|1988|p=76}.</ref>" ~ J. Johnson (JJ) (talk) 21:50, 28 September 2017 (UTC)

P.S. I forgot to mention that analogous to the situation described here (citing original text and its translation) is the citation of a primary source that is the original and well-known source of some important item, along with a secondary source that attests that the primary source is the original, etc., and perhaps explains it or provides context. ~ J. Johnson (JJ) (talk) 23:21, 28 September 2017 (UTC)

In contrast to what has been broadbrought forward above, I think that it is not our business to decide if a quote should be given as part of a citation, separately or not at all. It is a frequently used feature, so obviously editors find it convenient, useful and suitable.

For those cases, where the article editors use the |quote= parameter, we should also provide optional parameters |script-quote= and |trans-quote= in order to support editors in the best possible way.

When I use the |quote= parameter and want to give both the original text as well as a translation, I am at present forced to put both into the |quote= parameter. My personal style is to append the translation to the original text and put it in [square brackets] - similar to how |title= and |trans-title= are rendered. However, I am not happy with this solution as it lumps together two distinct pieces of information, and since the formatting is left to the editor rather than the template, it does not follow the fundamental principle of keeping content and presentation separate, and it makes it impossible for machines to properly parse the contents (and possibly process the original and the translation differently) later on. (Some reasons for why it might be useful to process strings differently might be down to future user preferences to mute translations if the reader is able to read the original language, to support screen readers, or to ease the reuse of quotes in external databases.)

Since the solution to this problem (which hasn't been broadbrought forward for the first time) is to just provide another parameter and concat the strings internally in the template (instead of letting the editors do it), it would be trivially easy to implement.

--Matthiaspaul (talk) 21:39, 22 October 2017 (UTC)

Did you mean 'brought forward'?

I do not doubt that editors find [|quote=] convenient, useful and suitable. I do not think that these same editors have ever really thought about it; it is there, they use it, and I would guess that they do this in the belief that we have thought about it.

The purpose of a citation is to identify the source that supports Wikipedia-article content. It is not the purpose of a citation to be a surrogate for that source. If you require content and presentation to be separate, why do you not also require source-content to be separate from source-identification?

—Trappist the monk (talk) 11:32, 23 October 2017 (UTC)

Whatever the pros and cons of quote=, as policy (WP:NONENG) says "translation into English should always accompany the quote", I would support quote-trans=, and quote-translator= too. For this time being I put, eg quote="Ich bin ein Berliner (I am a doughnut)", which *is* easy enough, but the extra attributes would encourage NONENG to be followed. Batternut (talk) 13:04, 11 November 2017 (UTC)

Access date error on kannada wikipedia

Citation error of access date seen on following help pages on English wikipedia Template:Cite_web & kannada wikipedia kn:Template:Cite_web, in reference we get Check date values in: |access-date= (help) , we getting error on kn:Category:CS1_errors:_dates at kannada wikipedia, does some one know how to fix it. this issue with access date only. ★ Anoop / ಅನೂಪ್ ^✉ _© 13:44, 26 September 2017 (UTC)

I don't see any errors on en:Template:Cite web. At kn:Template:Cite_web, there is this:

|access-date={{date|{{date}}|mdy}}

which at kn.wiki produces a date that looks like this:

೨೨ ಸೆಪ್ಟೆಂಬರ್ ೨೦೧೭ (google translate thinks that is 22 Sepṭembar 2017)

As written, kn:Module:Citation/CS1/Date validation does not support month names in Kannada and may not support Kannada numerals in all cases.

Just as an experiment at kn:Module:Citation/CS1/Date validation in the debug console I wrote:

=mw.ustring.match ('೨೨ ಸೆಪ್ಟೆಂಬರ್ ೨೦೧೭', '%d%d%s+%a+%s+%d%d%d%d')

that should have matched but didn't. The %a+ should match one or more unicode letters so apparently ಸೆಪ್ಟೆಂಬರ್ (U+0CB8 U+0CC6 U+0CAA U+0CCD U+0C9F U+0CC6 U+0C82 U+0CAC U+0CB0 U+0CCD) has stuff that isn't letters in it. This worked:

=mw.ustring.match ('೨೨ ಸೆಪ್ಟೆಂಬರ್ ೨೦೧೭', '%d%d%s+[%D%S]+%s+%d%d%d%d')

where [%D%S]+ matches one or more of anything that isn't digits and spaces.

You might want to ask Editor kn:User:Omshivaprakash what the purpose of this edit was. I think that that this change:

elseif 'access-date'==k then                                    -- if the parameter is |date=
--	good_date = check_date (v, nil, true);                  -- go test the date; nil is a placeholder; true is the test_accessdate flag

leaves good_date false which causes the access-date test to fail even if |access-date=2017-09-26 is used. So, fix that first.

Then, the challenge is going to be to rewrite portions of the module to understand Kannada months and then see what other changes are needed.

—Trappist the monk (talk) 15:58, 26 September 2017 (UTC)

Today I copied the live en.wiki module suite to the kn.wiki sandboxen. I have discovered that in the process of validating |access-date= at kn.wiki (and presumably other wikis whose local languages do not use the Western digit set [0-9]) that the timestamps created by calls to mw.getContentLanguage():formatDate() are returned as text strings in the local script. In order to compare a string of character digits to the number that defines the start of Wikipedia, the new timestamp strings must be converted to numbers. At en.wiki tonumber() does the trick. But, at kn.wiki, tonumber() returns nil which causes a huge red script error. I have added an alternative for use on kn.wiki and others that may require it.

—Trappist the monk (talk) 16:11, 11 November 2017 (UTC)

Further work on the kn.wiki module was necessary because any dmy, mdy, my, essentially any date with kn script month names ('೨೨ ಸೆಪ್ಟೆಂಬರ್ ೨೦೧೭') failed. These dates failed because all of the tests in the en.wiki code copied to kn.wiki use %a+ character classes in the patterns that are used to detect the date formats. But, as noted above, %a+ doesn't work because kn script has additional 'character modifiers'(?) that tweak how a character is rendered. These character modifiers are not %a+ so the mw.ustring.match() stops looking when it discovers these character modifiers. To get round that, kn.wiki now uses %D which matches any character that is not %d (digits). So, instead of writing:

mw.ustring.match(date_string, "^[1-9]%d? +%a+ +[1-9]%d%d%d%a?$")

we can write:

mw.ustring.match(date_string, "^[1-9]%d? +%D- +[1-9]%d%d%d%a?$")

to accomplish the same thing.

Another problem at kn.wiki is that, internally, Lua apparently doesn't understand unicode digits that aren't the generic ASCII 0–9; the characters can be detected with %d but it is not possible do math (೨+೭) with these characters. To get round that, I've created a table of 'local language' digit characters and their ASCII equivalents. A line of code in check_date() uses that table to convert 'local digits' to ASCII so that the module can properly evaluate the numbers that are part of all dates supported by cs1|2.

I have come to realize that there is no reason why kn.wiki's Module:Citation/CS1/Date validation should be different from the same module at en.wiki. Because of that, I have made these same changes to the en.wiki /Date validation and /Configuration sandboxen. These changes, support better internationalzation.

—Trappist the monk (talk) 01:17, 13 November 2017 (UTC)

Full vs truncated number for end of page-range

For {{cite journal}} and friends, should we use |pages=2041–2043 or |pages=2041–43? Last year, MOS:DATERANGE determined that full years should (almost) always be used for the end of year-ranges, but MOS:NUM is silent about the more general idea of ranges and I can't find any statement in the docs for the various citation templates about it. DMacks (talk) 21:30, 27 September 2017 (UTC)

Probably mute on the subject because there is little need to micromanage. If one were in need of saving ink or were attempting to squeeze the citation into the last available space on a crowded page, then truncation would be an option to accomplish those goals. But, we don't use ink, and space is not a problem. And, for some, reading anything that's truncated causes a stutter in the flow.

—Trappist the monk (talk) 21:51, 27 September 2017 (UTC)

I think there is no one citation style for page ranges, and it probably depends on the conventions of the field. The Chicago manual of style has one such set of rules about page range style. As Trappist says, publishers cared about good compression for printing, but we don't have the problem here. Use what you think is best. --Mark viking (talk) 22:03, 27 September 2017 (UTC)

I agree with the above, consistency within the same article is probably more important. —PaleoNeonate – 23:16, 27 September 2017 (UTC)

The same logic applies to page number ranges, obviously. The problem with things like "2943–76" is they are not immediately parseable for what they're intended to be, and worse yet, they can often coincide with numeric dates, e.g. "1902–11" (remember that many fonts do not clearly distinguish - and –).  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  08:23, 3 October 2017 (UTC)

Yep. Also, they are neither used nor understood everywhere. Since our MOS advises against using abbreviations unless they can be expected to be understood by anyone, and also because "Wikipedia is not paper", I replace such abbreviated page ranges by their expanded form when I run into them - and so far noone ever complained. --Matthiaspaul (talk) 17:55, 22 October 2017 (UTC)

Years and Classical publications from Antiquity

This seems to throw an error when using dates of Classics

{{cite book|year= 8|title= ABC|author= ZYX}}

ZYX (8). ABC. {{cite book}}: Check date values in: |year= (help)CS1 maint: year (link)

{{cite book|year= 8 AD|title= ABC|author= ZYX}}

ZYX (8 AD). ABC. {{cite book}}: Check date values in: |year= (help)CS1 maint: year (link)

{{cite book|year= 56 CE|title= ABC|author= ZYX}}

ZYX (56 CE). ABC. {{cite book}}: Check date values in: |year= (help)CS1 maint: year (link)

{{cite book|year= 56|title= ABC|author= ZYX}}

ZYX (56). ABC. {{cite book}}: Check date values in: |year= (help)CS1 maint: year (link)

{{cite book|year= 267|title= ABC|author= ZYX}}

ZYX (267). ABC.

{{cite book|year= 124 BCE|title= ABC|author= ZYX}}

ZYX (124 BCE). ABC. {{cite book}}: Check date values in: |year= (help)CS1 maint: year (link)

{{cite book|year= -56|title= ABC|author= ZYX}}

ZYX (-56). ABC. {{cite book}}: Check date values in: |year= (help)CS1 maint: year (link)

{{cite book|year= 3 BC|title= ABC|author= ZYX}}

ZYX (3 BC). ABC. {{cite book}}: Check date values in: |year= (help)CS1 maint: year (link)

It appears to need a three digit absolute magnitude value or greater. This is clearly an error in the processor. -- 70.51.46.15 (talk) 06:57, 11 October 2017 (UTC)

This topic is related to this citation? Forgive my skepticism, but I suspect that you are not directly citing a first century CE copy of Metamorphoses, but are citing a rather more recent edition. That being the case, then the appropriate date for the citation would be the date of the source that you consulted. At en.wiki, WP:SAYWHEREYOUGOTIT applies.

Also, your post here is a duplicate of a post you made at Help talk:CS1 errors#Years and Classical publications from Antiquity. One conversation in one place only, please.

—Trappist the monk (talk) 11:22, 11 October 2017 (UTC)

Photographs of published Latin works do exist, and there have been digitization efforts as well. So, accessing such, would the date the work was digitized or photographed be your "source date" ? This is a generalized query, since I've used old Latin sources for other things in the past (though with triple or quadruple digit years) I would expect that the citation template should work for older dates as well. Some Wikipedian editors can read Latin or Greek or Hebrew or Chinese, so ancient documents are accessible to some of the general population of editors here at Wikipedia, thus the citation template should be able to support this editor population. -- 70.51.46.15 (talk) 05:23, 12 October 2017 (UTC)

Unless you're literally at a museum looking at manuscripts/tablets/whatever dating from antiquity, I don't see how there would be an issue. Can you give an example where the date of publication (not the date of authorship) of a source you cite would be in the double digits?

Edit: Personally for a well known text such at the Metamorphoses you can probably just do

{{cite book|author=Ovid|title=Metamorphoses|at=II.153}}

Ovid. Metamorphoses. II.153.

That's generally how I've works like the CMoS say to cite classical works unless it really matters which edition you're using, e.g., if there's some debate as to the original text. Umimmak (talk) 09:29, 12 October 2017 (UTC)

I do not deny that facsimiles of sources exist nor that there are editors here who can read them. Facsimiles abound on the internet:

Ovid (1889). "Book the Second: Fable I". In Riley, Henry T. (ed.). Metamorphoses. Translated by Riley. London: George Bell & Sons. p. 51.

But apparently, there are no surviving first-century manuscripts of Metamorphoses (so says the en.wiki article). The lack of surviving first-century manuscripts and WP:SAYWHEREYOUREADIT suggest that citing Metamorphoses and using |year=8 AD is inappropriate. Cite the source that you read.

When the cs1|2 templates were first written, there were technical reasons for limiting minimum |year= values to three digits. While the technical limitation no-longer applies because of new technology, the constraint was left in and, but for the occasional case like the one in hand, there has been little call to extend date-handling support to cover all time. When the scholars of ancient texts take up their pitchforks and torches and clamber for ancient-date support in cs1|2, we can certainly consider it.

—Trappist the monk (talk) 11:18, 12 October 2017 (UTC)

Since Chinese over the last 2000 years is readable to modern Chinese readership, if they've been trained to read Classical Chinese (ie. 19th century Chinese and before) I would say that such sourcing would be expected for some topics. Or if you're a Brahmin and quoting Sanskrit sources of the past 3000 years. -- 70.51.46.15 (talk) 04:46, 14 October 2017 (UTC)

Again, the year something was originally written is distinct from the year of publication of the source the editor got the text from. Umimmak (talk) 05:34, 14 October 2017 (UTC)

There are still good reasons to mark three-digit years as an error. Most three-digit years, like "year=207", are typos for four-digit years, like "year=2017". The error check finds these frequently. – Jonesey95 (talk) 01:41, 13 October 2017 (UTC)

Shouldn't this be able to be specified with an override of some sort, like providing "BCE" or "AD" in the parameter ? Or a plus or a minus sign? (ie. French-style dates with minus-signs for BC dates) -- 70.51.46.15 (talk) 04:38, 14 October 2017 (UTC)

|orig-year= works well for citing the original publication dates of older works. – Jonesey95 (talk) 13:56, 11 October 2017 (UTC)

I think you need a |date= as well though, see: {{cite book|author=Ovid|title=Metamorphoses|at=II.153|orig-year=8 AD}} which produces Ovid. Metamorphoses. II.153. Umimmak (talk) 09:29, 12 October 2017 (UTC)

{{cite book|orig-year= 8|title= ABC|author= ZYX}}

ZYX. ABC.

{{cite book|orig-year= 8|year= AD 8|title= ABC|author= ZYX}}

ZYX (AD 8) [8]. ABC. {{cite book}}: Check date values in: |year= (help)CS1 maint: year (link)

That "|orig-year=" indeed does not provide the year unless "|year=" is specified per Umimask. -- 70.51.46.15 (talk) 04:38, 14 October 2017 (UTC)

Special formatting for lists of works by an author.

This is a feature request. In lists of works by the subject of an article, eg. Andrea Gallo#Works, I tend to use author-mask=1 so the date comes first. In works with more than one author, I wish there was a parameter for {{cite}} which would show the date first and then list secondary authors prefixed by "with" after the date. Thank you. Sondra.kinsey (talk) 16:52, 14 October 2017 (UTC)

May I point out that the first entry in any masked list should have the full citation reference, including the name of the author. Otherwise it is unclear what exactly you are masking. This holds for works by an article's subject as well, even when it is obvious who the author is. Secondly, in most citation applications, works are universally indexed by author(s) first (though some specialized systems may index by title/date rather than author/date). Since you decided to use CS1 to populate this list (a good idea, imo), the style should be followed. If this style doesn't suit your needs, I suggest formatting the list differently, without the strictures of CS1. 65.88.88.46 (talk) 17:55, 14 October 2017 (UTC)

Cite book problem

Does anyone know what is wrong with this?

{{cite book|last1=Mackie|first1=Gerry|editor1-last=Shell-Duncan|editor1-first=Bettina|editor2-last=Hernlund|editor2-first=Ylva|title=Female "Circumcision" in Africa: Culture, Controversy and Change|date=2000|publisher=Lynne Rienner Publishers|location=Boulder|chapter=Female Genital Cutting: The Beginning of the End​|​chapter-url=https://web.archive.org/web/20131029210333/http://www.polisci.ucsd.edu/~gmackie/documents/BeginningOfEndMackie2000.pdf|ref=harv}}

which produces two errors:

Mackie, Gerry (2000). "Female Genital Cutting: The Beginning of the End​". In Shell-Duncan, Bettina; Hernlund, Ylva (eds.). Female "Circumcision" in Africa: Culture, Controversy and Change. Boulder: Lynne Rienner Publishers. {{cite book}}: Invalid |ref=harv (help); Unknown parameter |​chapter-url= ignored (help); zero width space character in |chapter= at position 49 (help)

SarahSV ^(talk) 00:33, 16 October 2017 (UTC)

I don't know, but retyping the chapter title (without changing the chapter URL) seems to have fixed it:

{{cite book|last1=Mackie|first1=Gerry|editor1-last=Shell-Duncan|editor1-first=Bettina|editor2-last=Hernlund|editor2-first=Ylva|title=Female "Circumcision" in Africa: Culture, Controversy and Change|date=2000|publisher=Lynne Rienner Publishers|location=Boulder|chapter=Female Genital Cutting: The Beginning of the End|chapter-url=https://web.archive.org/web/20131029210333/http://www.polisci.ucsd.edu/~gmackie/documents/BeginningOfEndMackie2000.pdf|ref=harv}}

Mackie, Gerry (2000). "Female Genital Cutting: The Beginning of the End" (PDF). In Shell-Duncan, Bettina; Hernlund, Ylva (eds.). Female "Circumcision" in Africa: Culture, Controversy and Change. Boulder: Lynne Rienner Publishers. {{cite book}}: Invalid |ref=harv (help)

—David Eppstein (talk) 00:37, 16 October 2017 (UTC)

David, thank you! I wonder whether there was an invisible character in the chapter title. SarahSV ^(talk) 00:40, 16 October 2017 (UTC)

U+200B zero-width space. With your cursor highlight the 'E' in 'End'. Walk the highlight one character at a time to the right. You will notice that it takes an extra step to get from the 'd' in 'End' to the chapter's closing double quote character. And, interestingly enough, that is position 49 in the |chapter= parameter value, just as the error message said. Isn't that amazing?

—Trappist the monk (talk) 00:49, 16 October 2017 (UTC)

@SlimVirgin: (EC) There was one yes End​<INVISIBLECHARACTER>|chapter-url. You can find it by counting 49 character positions in |chapter=. Put your cursor there, hit delete. Nothing will apparently happen, but you've deleted the invisible character. Headbomb {t · c · p · b} 00:51, 16 October 2017 (UTC)

Thanks, everyone. SarahSV ^(talk) 22:34, 16 October 2017 (UTC)

5-Digit volume numbers not rendered in boldface by ((cite book))

The Springer book series Lecture Notes in Computer Science has meanwhile reached volumes >10000. Such 5-digit volume numbers aren't rendered in boldface, while shorter numbers are. See the 2017 entry at Conference on Artificial General Intelligence#References for an example. Maybe somebody can fix this. Thanks in advance! - Jochen Burghardt (talk) 08:34, 17 October 2017 (UTC)

I think that this the most recent conversation that we've had on the topic.

Some would like volume bolding to go away; some would like to extend it to all characters; some would like another parameter that controls bolding. We have not been able to reach a consensus to change its current rendering.

—Trappist the monk (talk) 14:25, 17 October 2017 (UTC)

Through the years, this has been remarked on by normal people. There is no reasoning (that makes any sense logically, visually, or programmatically), for the font weight to depend on the variable's length. It runs counter to guidelines for consistency and uniformity, and keeps bringing people here to ask the same questions. I would withhold any thanks in advance. 72.43.99.146 (talk) 14:32, 17 October 2017 (UTC)

I agree that bolding should be consistently enforced. Headbomb {t · c · p · b} 15:50, 17 October 2017 (UTC)

I don't care much if volumes are displayed in bold or not, but I do think that the output style should be consistent regardless of the data entered. Since shorter volume numbers are the common case, I think, longer volumes should follow that style as well. If that would create bad looking citations somewhere, people will start to complain sooner or later. This might lead to a discussion to remove boldface. Regardless of its outcome, we'd have achieved consistency at least. --Matthiaspaul (talk) 18:32, 22 October 2017 (UTC)

Were it up to me, I'd drop the boldfacing and prefix "Vol." or "vol." ahead of volume numbers. A single boldface number in the middle of a citation without any other clue as to its meaning isn't very helpful to readers who come from outside of the segment of academia that uses boldface numbers. (Ditto the formatting in {{cite journal}}; a little verbosity so that things are very clear for our readers is a good thing.) On that basis, when I use |volume= in {{cite book}}, I manually insert "vol.", which bypasses the boldfacing. Since that's 5 characters, plus the numbers, if we switched the default to bold up to 5 and drop the bold on 6+, my desired template behavior would still work properly. Imzadi 1979 → 21:23, 22 October 2017 (UTC)

I've been thinking that it would be nice to make it obvious to readers the intent of |volume= as well as |issue= in cite journal i.e. rendering it equivalently to the current cite magazine. I suspect, however, it would require an RFC prior, since that change seems likely to be contested. --Izno (talk) 05:11, 9 November 2017 (UTC)

automatic |format=pdf

In the wild I discovered a reference that rendered with the (PDF) annotation but the url did not point to a pdf file. Module:Citation/CS1 is confused by a url that ends '.pdf.html'.

Cite web comparison

Wikitext	{{cite web|title=Title|url=//example.pdf.html}}
Live	"Title".
Sandbox	"Title".

Fixed in the sandbox.

—Trappist the monk (talk) 14:19, 17 October 2017 (UTC)

Example of book with journal-like properties, chapter authors and issue plus number indicators

Interesting example of a (hardcopy) book (with ISBN), which is part of a book series (with ISSN) and has volume, issue and number indicators (similar to a journal). Also, it contains at least one chapter by a pair of authors completely different from those authors responsible for the remainder of the book (and listed on the front cover) and the series editor. The volume number (V) is incremented every year, the issue number (I) is incremented for each book published in that year in the series (just like in a journal, except for that the number of issues in a year seems to be variable), and the number (N) is apparently a running number counting up from the first book in that publisher's series (the publisher publishes multiple series of books). So, I need either or both the {{cite book}} and {{cite journal}} template to support something like this:

Steinbach, Bernd; Posthoff, Christian. Chapter 3: Boolean Differential Calculus. In: Sasao, Tsutomu; Butler, Jon T. (2010-01-15). Thornton, Mitchell A., ed. "Progress in Applications of Boolean Functions". Synthesis Lectures on Digital Circuits and Systems. 4 (1) #26 (1st ed.). San Rafael, CA, USA: Morgan & Claypool Publishers: 55–78. ISBN 978-1-60845-181-4. ISSN 1932-3166.

Issues with the current template implementation:

• The {{cite journal}} template does not support the |chapter= parameter. This is an artificial restriction based on the invalid assumption that there are no chapters in journal articles. Over the years, a lot of examples have been brought forward in older discussions showing that some longer journal articles do have chapters, and that it can be necessary to cite them individually. Let's fix this.
• Also, it is necessary to support either |series= or |work= in parallel to |chapter=.
• Since chapter author(s) are not always the same as the author(s) listed as article or book author(s) on the front, it is necessary to support a set of optional |chapter-author*= parameters when |chapter= is given as well. In some cases this can be worked around by abusing the |editor*= parameters to specify the book authors but the given example even has a series editor, so the |editor*= parameters are needed for him.
• The {{cite book}} template currently ignores the |issue= and |number= parameters - but it should support them.
• The {{cite journal}} template supports them, but handles both of them the same and does not allow both to be specified at the same time. Instead, it should allow both to be specified at the same time and (only) then use |issue= as a parameter for volume-specific numbers and |number= for independent numbers. I suggest to render this as:

V (I) #N

(If both issue and number cannot be put into meta-data at the same time, the number should be ignored in the meta-data (at least for the time being) but still be shown in the visual output.)

This would be a fully-backward compatible extension to the currently supported forms

V (I)

or

V (N)

if only one out of |issue= and |number= is given.

Thanks. --Matthiaspaul (talk) 01:39, 19 October 2017 (UTC)

Yeah I agree, it'd be nice to have issue number for books; right now a workaround is just to do {{citation|mode=cs1|...}}, which seems to allow more options. I've also been using "contribution" if the author of a chapter isn't the author (not editor) of the rest of the book. Umimmak (talk) 02:06, 19 October 2017 (UTC)

I think I would just do this and move on:

Steinbach, Bernd; Posthoff, Christian (2010-01-15). "Chapter 3: Boolean Differential Calculus". Progress in Applications of Boolean Functions. By Sasao, Tsutomu; Butler, Jon T. Thornton, Mitchell A. (ed.). Synthesis Lectures on Digital Circuits and Systems. Vol. 4:1 (#26) (1st ed.). San Rafael, CA, USA: Morgan & Claypool Publishers. pp. 55–78. ISBN 978-1-60845-181-4. ISSN 1932-3166.

That certainly gives readers enough information to be able to definitively locate the source. – Jonesey95 (talk) 03:25, 19 October 2017 (UTC)

Concur. cs1|2 is a general purpose citation tool that is adequate to the needs of most citation requirements. It works quite well in that role. Being a general purpose tool prevents it from being a specialized, handle-all-citation-needs tool.

—Trappist the monk (talk) 09:26, 19 October 2017 (UTC)

internationalization

An editor at kn.wiki desires to fix the cs1|2 modules there; the original post about that is here.

Some months ago I tweaked the module suite at ht.wiki so that it worked correctly and as part of that added support for simple replacement of English month names with the appropriate Haitian Creole month names. Because date support at kn.wiki will have similar problems and because I would prefer to not have multiple variations of the base code at each different wiki (if it can be avoided) I have implemented the ht.wiki tweaks in the en.wiki sandbox. These changes should make it easier for other wikis to maintain currency with the en.wiki module suite.

Cite book comparison

Wikitext	{{cite book|accessdate=15 September 2017|date=Fall 2013|publication-date=Christmas 2013|title=Title|url=//example.com}}
Live	Title (published Christmas 2013). Fall 2013. Retrieved 15 September 2017. {{cite book}}: Check date values in: |publication-date= (help)
Sandbox	Title (published Christmas 2013). Fall 2013. Retrieved 15 September 2017. {{cite book}}: Check date values in: |publication-date= (help)

—Trappist the monk (talk) 11:17, 19 October 2017 (UTC)

edtf experiment removed

See Help talk:Citation Style 1/Archive 33#edtf date formats as cs1|2 date parameter values. Because there is apparently no support for this 'solution', I have removed the experimental code that supported it.

—Trappist the monk (talk) 11:42, 19 October 2017 (UTC)

I think EDTF is a good idea, but in order to not confuse bots trying to make sense of the |date= parameter, perhaps it should be implemented as a new parameter like |edtf-date= or similar. --Matthiaspaul (talk) 00:28, 20 October 2017 (UTC)

If a bot is able to find and properly evaluate |edtf-date= it can find and properly evaluate |date= else it has no business being a bot.

—Trappist the monk (talk) 12:44, 21 October 2017 (UTC)

;-) Yes, of course. I didn't see much opposition against this format (after all, it's optional), but since you mentioned a lack of support, it was my assumption that the only possible reason not to support such an extension would be that it would somehow interfere with existing functionality here or elsewhere. Hence the idea of putting it into a separate parameter (for now), so we can be sure that it will be interpreted only by bots, spyders (and humans) who know how to interpret it, thereby eliminating the risk that these strings would end up in databases uninterpreted or even interpreted incorrectly. Well, that happens with other unknown date formats as well, so this is not a strong argument. Personally, I'm not against supporting EDTF in the |date= parameter. --Matthiaspaul (talk) 14:26, 21 October 2017 (UTC)

I don't like having unused code lying about in the module suite. If we need it sometime in future, we can troll through the old versions and get it back. Because Citoid doesn't now, and as far as I can see from recent posts at T132308, may never support edtf, I don't see a need at present to support it.

—Trappist the monk (talk) 15:18, 21 October 2017 (UTC)

edtf is now part of ISO DIS 8601 2016. Because of that, and because we may someday return to this topic, I have changed the season numbering that Module:Citation/CS1/Date validation/sandbox uses to internally represent seasons. This change does not mean that suddenly |date=2017-23 is an acceptable numeric date that means Autumn 2017. We could do that but this change does not consider that.

This change does remove the season-order checking because there are cases like this double issue where |date=Spring–Winter 1971 is appropriate.

—Trappist the monk (talk) 12:44, 21 October 2017 (UTC)

Long institutional author name with commas in it.

In Nancy Temkin I have a source whose authors are "National Research Council, Institute of Medicine, Board on Children, Youth, and Families, Committee on Sports-Related Concussions in Youth", which I have placed into the |author= parameter. This puts the article into an inappropriate maintenance category, Category:CS1 maint: Multiple names: authors list. It is not a multiple-name author list; it is a single institutional author name that happens to have commas in it. How do I avoid the maintenance category and the inevitable bot mangling of this name? —David Eppstein (talk) 17:34, 19 October 2017 (UTC)

You might consider rewriting the citation in the form that the publisher recommends on this page:

{{citation |page=2037 |url=https://books.google.com/books?id=DBafAwAAQBAJ&pg=PA2037 |title=Sports-Related Concussions in Youth: Improving the Science, Changing the Culture |author=Institute of Medicine (IOM) and National Research Council (NRC) |location=Washington DC |publisher=National Academies Press |year=2014 |isbn=9780309288033}}

Institute of Medicine (IOM) and National Research Council (NRC) (2014), Sports-Related Concussions in Youth: Improving the Science, Changing the Culture, Washington DC: National Academies Press, p. 2037, ISBN 9780309288033

The publisher's recommendation seems to match the attribution stated on the cover image of the Google books facsimile except that it leaves off 'of the National Academies'.

Were it me, I'd write |author=Institute of Medicine |author2=National Research Council because they are separate entities.

—Trappist the monk (talk) 18:00, 19 October 2017 (UTC)

Discussion on whether/how to add citations to papers on university repositories

Wikipedia talk:WikiProject Open#OA repository links

Cheers, Ocaasi (WMF) (talk) 23:15, 19 October 2017 (UTC)

Partial script-title and title mixup

The display of |script-title= and |title= is partially mixed up. What defines and therefore what should be displayed as the title of the work is always what is printed on the book or article itself (this holds true in general, even if the title is written in a foreign script). If known and necessary, it is helpful to also display transliterations and translations, however, since neither of them is without ambiguities (several transliteration systems existed and continue to exist, and translations are even more subject to interpretation) and they are therefore only weak identifiers, this is only auxiliary information, not authorative. If only one of the two parameters is given, the {{cite journal}} template displays them as title, which is fine. However, if both are given at the same time, the template displays the actual title (then given in |script-title=) only as secondary information (after the transliteration in quotes) thereby creating the invalid impression that the transliterated title would be the actual title. Example:

{{cite journal |author-first=А. Д. |author-last=Таланцев |script-title=ru:б анализе и синтезе некоторых электрических схем при помощи специальных логических операторов |title=Ob analize i sinteze nekotorykh električeskikh skhem pri pomośći special'nykh logičeskikh operatorov |language=Russian |trans-title=On the analysis and synthesis of certain electrical circuits by means of special logical operators |journal=Автоматика и телемеханика |volume=20 |number=7 |date=1959 |pages=898–907}}

erroneously renders as:

Таланцев, А. Д. (1959). "Ob analize i sinteze nekotorykh električeskikh skhem pri pomośći special'nykh logičeskikh operatorov" б анализе и синтезе некоторых электрических схем при помощи специальных логических операторов [On the analysis and synthesis of certain electrical circuits by means of special logical operators]. Автоматика и телемеханика (in Russian). 20 (7): 898–907.

but should instead render as (round brackets added by me as another suggestion):

Таланцев, А. Д. (1959). "б анализе и синтезе некоторых электрических схем при помощи специальных логических операторов" (Ob analize i sinteze nekotorykh električeskikh skhem pri pomośći special'nykh logičeskikh operatorov) [On the analysis and synthesis of certain electrical circuits by means of special logical operators]. Автоматика и телемеханика (in Russian). 20 (7): 898–907.

There's another (only remotely related) issue: If only a |trans-title= is given, but neither |script-title= nor |title=, the template does not display a title at all. While this is not a hard error, I think it would be beneficial if the translation gets displayed anyway (in [brackets], of course), perhaps with an edit-time warning "Missing title parameter!" or similar. This would make it easier for editors to identify the actual source and retrofit the actual title.

--Matthiaspaul (talk) 18:16, 20 October 2017 (UTC)

On the only remotely related issue, yep, broken, now fixed in the sandbox:

And on the other, I think that the styling decision comes from this conversation.

—Trappist the monk (talk) 19:25, 20 October 2017 (UTC)

Thanks for the fix and the pointer - there's a lot of interesting stuff in that old thread, much appreciated.

--Matthiaspaul (talk) 13:53, 21 October 2017 (UTC)

Your view on the presentation of titles is not shared by The Chicago Manual of Style, which suggests that original titles in Chinese or Japanese characters be placed after the romanized title. (It does not suggest original titles for other non-Latin scripts.) Nor is it plausible that anyone would mistake a romanized title placed before a script title for the original title – the only reason to include a title in a non-Latin script would be if it were the original title. Kanguole 20:08, 20 October 2017 (UTC)

Thanks for pointing out CMOS' suggestions for Chinese and Japanese titles, I wasn't aware of them.

While I still find it somewhat counter-intuitive to not put the most authorative title first, and, according to the old thread, I'm not alone with that opinion, following an established standard is more important (unless there were strong reasons to not follow it). So, I agree with you that the order of titles should remain:

<transliterated_title> <scripted_title> <translated_title>

What I did not find addressed in the other thread is the transliterated title to be put in "quotes". Somehow, I associate those quotes with the original title. So, with both |script-title= and |title= given, wouldn't it be better if the quotes were moved to the Cyrillic title? Like in:

Таланцев, А. Д. (1959). Ob analize i sinteze nekotorykh električeskikh skhem pri pomośći special'nykh logičeskikh operatorov "б анализе и синтезе некоторых электрических схем при помощи специальных логических операторов" [On the analysis and synthesis of certain electrical circuits by means of special logical operators]. Автоматика и телемеханика (in Russian). 20 (7): 898–907.

In some Asian scripts, the quotes could be replaced by corner brackets etc.

Only in absence of |script-title= the quotes should fall back to the "next-best" title representation in |title=.

Pros? Cons?

--Matthiaspaul (talk) 13:53, 21 October 2017 (UTC)

In the Chinese and Japanese examples given in CMOS, the romanized titles are surrounded by quote marks, and the original titles are unadorned. Kanguole 14:10, 21 October 2017 (UTC)

And that is how {{cite journal}} renders titles that include |script-title=:

{{cite journal |title=Romanized Title |script-title=Script Title |trans-title=Trans Title}}

"Romanized Title" Script Title [Trans Title]. {{cite journal}}: Cite journal requires |journal= (help); Invalid |script-title=: missing prefix (help)

And also how {{cite book}} renders chapter titles that include |script-chapter=:

{{cite book |title=Title |chapter=Romanized Chapter |script-chapter=Script Chapter |trans-chapter=Trans Chapter}}

"Romanized Chapter" Script Chapter [Trans Chapter]. Title. {{cite book}}: Invalid |script-chapter=: missing prefix (help)

Similarly, for titles that would be italicized:

{{cite book |title=Romanized Title |script-title=Script Title |trans-title=Trans Chapter}}

Romanized Title Script Title [Trans Chapter]. {{cite book}}: Invalid |script-title=: missing prefix (help)

—Trappist the monk (talk) 15:00, 21 October 2017 (UTC)

Sfn / VE

Anywhere t establish how? Tried adding sfn template- two big lines with ref text results! CHEERS — fortunavelut luna 13:37, 21 October 2017 (UTC)

What? I cannot decode what you have written. Can you clarify? Example?

—Trappist the monk (talk) 13:41, 21 October 2017 (UTC)

Virtual editor and a SFN

Yes indeed, many thanks! Using virtual editor- and trying to use the short notation. If it's used by inserting as a template, then the result is ----->

Most odd! Any ideas, Trappist the monk? This is the article in question, btw. — fortunavelut luna

No idea. Except that the {{sfn}} template is on its own line (shouldn't be), I don't see what you are seeing in the current article. That makes me suspect VE (an abomination in my opinion – full disclosure here) or possibly, though unlikely, your browser. Perhaps raise this issue at Wikipedia:VisualEditor/Feedback.

—Trappist the monk (talk) 13:59, 21 October 2017 (UTC)

Many thanks Trappist the monk. Yes, I'l be returning to BASIC model at least in order to finish the blooming thing off. The annoying thing about VE (well one of them perhaps) is that it lures one in with how easy certain things are... and then does something like this to waste an hour of one's ******* editing time: FFS. Thanks for your advice, anyway! Take care. — fortunavelut luna 14:07, 21 October 2017 (UTC)

Volume, issue, article, and page numbers

Some academic journals, especially on-line ones, maintain a volume/issue numbering, but no longer assign sequential page numbers within issues. Rather, each article has a number, and its page numbers start at 1.

For example, consider

• Agnese, R.; et al. (SuperCDMS Collaboration) (2017-04-07). "Projected sensitivity of the SuperCDMS SNOLAB experiment" (PDF). Physical Review D. 95 (8): 082002. arXiv:1610.00006. doi:10.1103/PhysRevD.95.082002. {{cite journal}}: Unknown parameter |class= ignored (help)

It's volume 95, issue 8, article number 082002, pages 1 through 17. This journal actually numbers the pages 082002-1 through 082002-17, but there are others which do not. Normally, I abuse the "page number" parameter for the article number, but it becomes awkward if I'd like to cite a particular page of an article. Is there a suggested way to deal with this? (One is to take the page number out of the citation template and use {{Rp}}.) 104.153.72.218 (talk) 09:38, 22 October 2017 (UTC)

Do it the usual way. If you want to cite page 15 specifically, do

• See p. 082002-15 in Agnese, R.; et al. (SuperCDMS Collaboration) (2017-04-07). "Projected sensitivity of the SuperCDMS SNOLAB experiment" (PDF). Physical Review D. 95 (8): 082002. arXiv:1610.00006. doi:10.1103/PhysRevD.95.082002. {{cite journal}}: Unknown parameter |class= ignored (help)
• Or Agnese, R.; et al. (SuperCDMS Collaboration) (2017-04-07). "Projected sensitivity of the SuperCDMS SNOLAB experiment" (PDF). Physical Review D. 95 (8): 082002 [082002-15]. arXiv:1610.00006. doi:10.1103/PhysRevD.95.082002. {{cite journal}}: Unknown parameter |class= ignored (help)

Headbomb {t · c · p · b} 12:06, 23 October 2017 (UTC)

Wikify journal based on ISSN

Have we reached the point with Wikidata where we can have the citation template auto-magically link the publication's dedicated WP article (if one exists) based on the citation's ISSN parameter? (E.g., if the publication param is not already wikified, lookup ISSN at Wikidata; if affiliated with a publication that has an enwp page, link said enwp page.) This would save writers like me a whole lot of lookup time. czar 20:04, 24 October 2017 (UTC)

I wouldn't be in favor of automatically linking them because if I cite the same publication multiple times, only the first footnote would/should be linked, and the others would not/should not be linked in keeping with the idea behind WP:OVERLINK. Additionally, not everyone likes to wikilink parts of a footnote, and those wishes should be accommodated. Imzadi 1979 → 16:47, 25 October 2017 (UTC)

I wouldn't being favour of it because that means cluttering our articles with virtually pointless ISSNs. Headbomb {t · c · p · b} 17:08, 25 October 2017 (UTC)

I don't think the ISSNs are pointless, quite to the contrary. Linking to an ISSN allows a reader to easily search WorldCat for a library that contains the journal or newspaper, whether it is in print or on microfilm. I honestly wish more libraries would link into WorldCat fore precisely that reason: discoverability, hopefully of local physical copies. Imzadi 1979 → 18:13, 25 October 2017 (UTC)

I agree. ISSNs are often quite useful. --Matthiaspaul (talk) 19:28, 25 October 2017 (UTC)

I wrote virtually pointless, not absolutely pointless. The vast majority of people go to their local library to find this stuff. If the library doesn't have it, the librarians track it down and make arrangements to get a copy of the journal article. If you want to call a library in Sweden yourself to get a copy of Filosofisk Tidskrift, I suppose you're always free to do so. But I don't know who would bother doing that.Headbomb {t · c · p · b} 19:39, 25 October 2017 (UTC)

The documentation for Cite journal seems incorrect. It describes the possibility of wikilinking the title parameter, but not the journal parameter. But Wikipedia is far more likely to have an article about a journal than an individual article from a journal. I would think the same would apply to Wikidata items. Jc3s5h (talk) 17:44, 25 October 2017 (UTC)

Really? What about this then?

• work: Name of the source periodical; may be wikilinked if relevant. Displays in italics. Aliases: journal, newspaper, magazine, periodical, website. (emphasis added)

Yep, more likely to be Wikipedia articles about a journal than about a journal article. Documentation can always be made better. Perhaps you could do something about that?

—Trappist the monk (talk) 18:56, 25 October 2017 (UTC)

Not related to cite templates, but Czar's question reminds me of an old project idea to create redirects in the form "ISSN nnnn-nnnn" for all articles about journals for which we know the corresponding ISSNs. Likewise, for all articles about books, we could create redirects in the form "ISBN n"* (in the various established formats with and without hyphens) for all known ISBN numbers associated with the corresponding book. This would allow users to enter an ISSN or ISBN into the search box and be redirected to the corresponding article. Obviously, this task would have to be bot-assisted. --Matthiaspaul (talk) 19:28, 25 October 2017 (UTC)

@Headbomb: Above suggestion up your alley regarding ISSNs?

@Matthiaspaul: You probably could do that, but it seems like filling out Wikidata with ISBN linkage would be better than filling in Wikipedia use. --Izno (talk) 12:52, 27 October 2017 (UTC)

That said, there are some feature requests related to Booksources on Phabricator that might also be relevant; notably phab:T5663. --Izno (talk) 13:00, 27 October 2017 (UTC)

ISSNs are not limited to journals. Several other types of serial works may use the identifier. Also, journals may have different ISSNs depending on media (print/digital etc.); different Series of the same journal (or other work, but journals are more likely to have distinct Series) may have different ISSNs. 65.88.88.69 (talk) 20:09, 26 October 2017 (UTC)

Yes, this publisher produces books that have both an ISBN and an ISSN, for example

• Marles, R.J. (1993). Collectors Coins Great Britain 1993 (20th ed.). Torquay: Rotographic. ISBN 0-948964-20-0. ISSN 0262-9712.
• Marles, R.J. (1995). Collectors Coins Great Britain 1995 (22nd ed.). Torquay: Rotographic. ISBN 0-948964-22-7. ISSN 0262-9712.

The idea is that since the book is updated annually, and the ISBN must necessarily change for each new edition, the ISSN is a constant which may be used to order the current edition without knowing the ISBN. --Redrose64 🌹 (talk) 21:05, 26 October 2017 (UTC)

Agree with Imzadi, above. Also: wikilinking a publication every time it is cited would surely be over-linking, right? ~ J. Johnson (JJ) (talk) 03:24, 27 October 2017 (UTC)

It's not overlinking. Overlinking applies to article text, not references. If you click on reference [129], citing Physical Review Letters, you don't care that Physical Review Letters was already linked in reference 26. Headbomb {t · c · p · b} 13:33, 27 October 2017 (UTC)

If "overlinking" applies only to article text, why is it so stiffly opposed in "See also" sections? How is it that replication of a link is a problem in the article text but not in the sources? ~ J. Johnson (JJ) (talk) 21:38, 27 October 2017 (UTC)

That's not overlinking in the sense of WP:OVERLINK. The "see also" section is to cover things that haven't been covered by the main article. See WP:SEEALSO. Headbomb {t · c · p · b} 05:14, 28 October 2017 (UTC)

I have always considered "See also" as a convenience for the reader in collecting all of the principal related topics in one spot, not just the ones not buried in the text somewhere. But never mind that.

The text at WP:OVERLINK starts with: "An overlinked article contains an excessive number of links", without quantifying "excessive". At the bottom – at MOS:DUPLINK – it says that "[g]enerally, a link should appear only once in an article" (emphasis in the original), then makes exceptions for footnotes (etc.), but not bibliographies. (Nor "references".) So how is having to hunt through a bibliography for the first mention of a publication any different than having to hunt through the entire article for the first mention of a related topic? ~ J. Johnson (JJ) (talk) 20:29, 29 October 2017 (UTC)

I would read the footnote exception as applying more broadly to reference sections in general. A lot of Wikipedia editors equate the two. —David Eppstein (talk) 20:49, 29 October 2017 (UTC)

The ambiguity of "reference" is such we should avoid it. But even equating it with a footnote, does not, as I see it, admit bibliographic sections, even when they are labeled "References". At any rate, that is more stretching of the text than is allowed for "See also" sections. ~ J. Johnson (JJ) (talk) 21:51, 29 October 2017 (UTC)

If overlinking isn't a problem in Bibliograpic sections, then presumably something like Corbett, Julian S. (1921). History of the Great War: Naval Operations: Volume II. London: Longmans, Green & Co. {{cite book}}: Invalid |ref=harv (help) is ok?Nigel Ish (talk) 23:19, 1 November 2017 (UTC)

Yes, that is the kind of situation I have in mind. A right proper sea of blue. And not treating the work of Corbett's arch-rival in the same would be a violation of using linking for unequal emphasis. ~ J. Johnson (JJ) (talk) 22:42, 2 November 2017 (UTC)

I think WP:OVERLINK "names of subjects with which most readers will be at least somewhat familiar" applies to the link on London, at least. I prefer to link authors and journal names whenever possible, but I'm not convinced of the value of links on publisher names. —David Eppstein (talk) 22:57, 2 November 2017 (UTC)

• Back to the original request, I think the social norms of the default CS1 implementation can be worked out by those concerned, but either way I'd like to see something along the lines of the proposal implemented at least for use at the editor's discretion, pulling the relevant journal name and/or wikilink (if available) when the citation's ISSN and a switch parameter are both set, perhaps such as |auto=y or |wikidata=y. Hell, it'd be really nice to even pull the ISSN if there are no conflicting publications by that name on Wikidata: |journal=Your Sinclair |auto=y => Your Sinclair (wikilinked). ISSN 0269-6983. czar 04:49, 6 November 2017 (UTC)

I am strongly against any "auto" replacement of parameter values from "the official database". As an option that would be a lot more palatable. But it seems to me that I've seen journals changing their name without changing their ISSN. That could raise a question of whether to use the current name, or the one (possibly abbreviated) found in the article itself. For this reason I think no replacement should be made unless the editor confirms it. ~ J. Johnson (JJ) (talk) 05:31, 6 November 2017 (UTC)

If the editor doesn't specify the parameter and explicitly chooses "auto", the implication is that the editor (such as myself) wants to supplement with the most current information. No one is being forced to use Wikidata, but given that it's built for this kind of usage, we should at least provide the option for those who want it. czar 17:24, 6 November 2017 (UTC)

I have no problem with an option to see the wikidata, in part as a check on spelling errors. I do have a problem with automatic insertion of that data without review. (Sure, I know how to Preview, but I fear many insufficiently experienced editors will not take the effort, or will even assume that the wikidata version is correct and/or better.) There is also the problem with predatory journals that use names very similar to authentic journals. If any discrepancy between the wikidata and what an editor has entered is clearly a typing error by the editor, fine, fix the error. But if the discrepancy is with what appears in the article, then a closer look should be taken.

Which reminds me: I think we should be consulting Beall's List of predatory journals. And while we might assume that ISSN's are authoritative (that is, not "stolen" by imitators), that needs to be checked. ~ J. Johnson (JJ) (talk) 22:06, 6 November 2017 (UTC)

The majority of those concerns appear better suited for other threads. I think it's more likely that "inexperienced" editors simply not know about an |auto= parameter rather than being prone to misusing it. In any event, if there is agreement that there should be some way to leverage Wikidata link support in citations, it would be more efficacious to build it into CS1 than for me to run some browser script to do the same in my browser. czar 22:35, 11 November 2017 (UTC)

If my suggestions for possible applications throws off the original intent, I'd simply like journal names to be automatically wikilinked to their respective articles (if such an article exists) when the user provides the ISSN and whatever switch parameter. This would make exporting citations from a citation manager much easier to link appropriately. czar 22:35, 11 November 2017 (UTC)

Not automatically! Editors should be responsible for what they add, and the minimum requirement of due diligence should be at least to preview and expressly approve of individual citations. ~ J. Johnson (JJ) (talk) 22:53, 11 November 2017 (UTC)

Plus we absolutely do not want to encourage adding near pointless ISSN clutter to citations. Headbomb {t · c · p · b} 23:10, 11 November 2017 (UTC)

I agree on this. ISSNs are useful only when one is unsure which journal is being named, which is very unusual for a properly-formatted citation. —David Eppstein (talk) 00:08, 12 November 2017 (UTC)

No one is suggesting that ISSNs be added where they are not needed. The case is specifically when the ISSN is provided and the journal name has the possibility of being linked based off of its Wikidata affiliation. And only triggered when specified by the editor. I work with small journals that often don't have their own Wikipedia articles, so the ISSNs are necessary. czar 19:09, 12 November 2017 (UTC)

"small journals that often don't have their own Wikipedia articles" still usually have unambiguous titles, so the ISSNs are not necessary; they are distracting and pointless clutter. —David Eppstein (talk) 19:58, 12 November 2017 (UTC)

Not even remotely true, and I don't know why you would make such a claim. Many mid-century journals consist of a single word and their lookup is a hell I wouldn't wish upon another. And even older journals have no ISSNs, making OCLC the only identifier: certainly vital for reference and in every sense the opposite of what you call it. I would appreciate if the discussion would stick to automated solutions for the problem I originally posed rather than the off-topic railing against ISSNs... czar 20:13, 12 November 2017 (UTC)

I think there are, in fact, cases where ISSNs are very useful. But if, in other cases, an editor thinks they are unnecessary, fine, don't add them. The only issue there is then whether some bot should be allowed to add them anyway. What you have proposed (as I understand it) is, given an |issn= parameter, "auto-magically link the publication's dedicated WP article ...." It's that "auto" part that I (and others) object to. ~ J. Johnson (JJ) (talk) 22:18, 12 November 2017 (UTC)

...when consciously set by the editor, the same way that other optional flags (e.g., |df= date format) are set. There's a difference between being a CS1 default and an optional aid to editors. As I said, the alternative is writing a userscript to the same effect, which seems like a waste when it's both easier to integrate and of greater public benefit to write the function as an optional CS1 param. If the phrase |auto= is a distraction, call it |wikidata=? The "auto" part is that the editor sets a specific parameter to let Wikidata provide the publication's wikilink rather than setting the link manually. It's simple and it keeps the link current. I don't see any reasonable capacity for error, abuse, or need for editor review apart from simply not trusting Wikidata. czar 22:57, 12 November 2017 (UTC)

It is not the term I object to, but the automatic inclusion of unverified data. Nor is there an '"auto" part [where] the editor sets a specific parameter' (your emphasis), such as setting "|issn=1011-9999". (I don't object to automatic placement and styling because involves no alteration or extension of the data.) What I object to is the extrapolation of an ISSN to an entirely different data item which is then automatically inserted without editorial preview or confirmation. Note that this does not mean that wikilinking must be done manually, only that there should be an expressed approval to continue.

BTW, there is plenty of scope for "editor review apart from simply not trusting Wikidata." But not trusting Wikidata is also valid. ~ J. Johnson (JJ) (talk) 23:50, 13 November 2017 (UTC)

|vauthors= and wikilinks

I have tweaked the code that supports |vauthors= and |veditors= so that wikilinked names are correctly handled and so that the metadata author information is not corrupted by the wikilink markup:

Cite book comparison

Wikitext	{{cite book|title=Title|vauthors=[[E. B. White|White EB]]}}
Live	White EB. Title.
Sandbox	White EB. Title.

Cite book comparison

Wikitext	{{cite book|title=Title|vauthors=[[White EB]]}}
Live	White EB. Title.
Sandbox	White EB. Title.
redlinked because there isn't a 'White EB' redirect page to 'E. B. White'

Cite book comparison

Wikitext	{{cite book|title=Title|vauthors=Lincoln A, [[E. B. White|White EB]]}}
Live	Lincoln A, White EB. Title.
Sandbox	Lincoln A, White EB. Title.

Compare the values assigned to the keywords &rft.aufirst and &rft.aulast:

Live (corrupted):

'"`UNIQ--templatestyles-000000AE-QINU`"'<cite id="CITEREFWhite" class="citation book cs1">[[E. B. White|White EB]]. ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.aulast=White&rft.aufirst=EB&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

Sandbox (not corrupted):

'"`UNIQ--templatestyles-000000B0-QINU`"'<cite id="CITEREFWhite" class="citation book cs1">[[E. B. White|White EB]]. ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.aulast=White&rft.aufirst=EB&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

—Trappist the monk (talk) 11:40, 25 October 2017 (UTC)

Noted elsewhere, but again, thanks for this. —David Eppstein (talk) 22:54, 2 November 2017 (UTC)

zwj in indic script

See Module_talk:Citation/CS1/Feature requests#Suppress spurious warning about zero-width joiner.

Module:Citation/CS1 detects invisible characters and when it does, it emits an error message. Among the detected characters is zero width joiner, ZWJ (U+200D). This character should not appear in normal Latin scripts but is extensively used in Indic scripts. I have added code that mutes the error message if the parameter value containing a ZWJ character has at least one character from any of these Unicode character sets:

Devanagari – 0900–097F – https://unicode.org/charts/PDF/U0900.pdf

Devanagari extended – A8E0–A8FF – https://unicode.org/charts/PDF/UA8E0.pdf

Bengali – 0980–09FF – https://unicode.org/charts/PDF/U0980.pdf

Gurmukhi – 0A00–0A7F – https://unicode.org/charts/PDF/U0A00.pdf

Gujarati – 0A80–0AFF – https://unicode.org/charts/PDF/U0A80.pdf

Oriya – 0B00–0B7F – https://unicode.org/charts/PDF/U0B00.pdf

Tamil – 0B80–0BFF – https://unicode.org/charts/PDF/U0B80.pdf

Telugu – 0C00–0C7F – https://unicode.org/charts/PDF/U0C00.pdf

Kannada – 0C80–0CFF – https://unicode.org/charts/PDF/U0C80.pdf

Malayalam – 0D00–0D7F – https://unicode.org/charts/PDF/U0D00.pdf

Conveniently, with the exception of Devanagari extended, all of the above are sequential so it is easy to write a Lua pattern for mw.ustring.find() that will find characters in the set 0900–0D7F.

Cite book comparison

Wikitext	{{cite book|language=ml|script-title=ml:തിരുവിതാംകൂര്‍}}
Live	തിരുവിതാംകൂര്‍ (in Malayalam).
Sandbox	തിരുവിതാംകൂര്‍ (in Malayalam).

Here, Latin script with ZWJ should show an error.

Cite book comparison

Wikitext	{{cite book|title=abc‍xyz}}
Live	abc‍xyz. {{cite book}}: zero width joiner character in |title= at position 4 (help)
Sandbox	abc‍xyz. {{cite book}}: zero width joiner character in |title= at position 4 (help)

—Trappist the monk (talk) 18:21, 25 October 2017 (UTC)

Module:Citation/CS1/COinS/sandbox tweaked to keep zwj characters in metadata when associated with Indic scripts.

—Trappist the monk (talk) 19:34, 29 October 2017 (UTC)

Development setup

I am trying to understand the templates in detail, in particular, in regard to date handling.

I have set up the following pages:

• User:Jc3s5h/Citation testcases
• User:Jc3s5h/cite-sand/Cite AV media

In the former, I have used {{Cite compare2}} and an invocation to the template in my user space.

I would like advice on whether I'm headed in the right direction in setting up an environment where I can test, and potentially improve, the templates. Jc3s5h (talk) 12:25, 26 October 2017 (UTC)

If, by the right direction, you mean to improve the current cs1|2 templates, perhaps not. {{cite arxiv}} uses wikitext markup to invoke a bot to fill in citation details; {{citation}} uses wikitext markup for making the determination to render cs2 version of {{cite patent}} which both use {{citation/core}} but are not part of the cs1|2 suite of templates. With those exceptions, all cs1|2 templates use the module suite. A list of all of the modules used by cs1|2 is at the top of Module:Citation/CS1. If you wish a more complete understanding of the cs1|2 templates, start there.

Certainly your User:Jc3s5h/Citation testcases can be tweaked to allow you to test the differences that exist between the live and sandbox versions of the templates (they are very unlikely to change) and between the live and sandbox versions of the modules (which change quite often).

—Trappist the monk (talk) 13:31, 26 October 2017 (UTC)

yet more parameters to deprecate

There are still some parameters that should have been deprecated and removed a long time ago pursuant to this rfc. They are:

• |doi_brokendate=
• |doi_inactivedate=
• |trans_chapter=
• |trans_title=

All of these have hyphenated counterparts.

I have deprecated these parameters in the sandbox.

—Trappist the monk (talk) 16:39, 27 October 2017 (UTC)

And one more:

• |template doc demo=

—Trappist the monk (talk) 16:49, 27 October 2017 (UTC)

Just for reference, at this time:

• doi_brokendate has 160 uses in mainspace,
• doi_inactivedate has 130 uses in mainspace
• trans_chapter has 1.5k uses in mainspace,
• trans_title has 55k uses in mainspace,
• template doc demo has 180 uses in all spaces.

--Izno (talk) 17:05, 27 October 2017 (UTC)

I support this continued standardization. Do we have an approved bot that can rename deprecated parameters in these templates? – Jonesey95 (talk) 18:56, 27 October 2017 (UTC)

We might add them to Wikipedia:AutoWikiBrowser/Rename template parameters. I don't know how effective that will be but if that is part of AWB's general fixes (which I never use, so I don't know) then a start could be made now. If that works, then perhaps no need for a bot (and the attendant headaches and delays that are BRFAs).

—Trappist the monk (talk) 19:17, 27 October 2017 (UTC)

I don't see BRFAs being very problematic here. The question is mostly why deprecate trans_title/trans_chapter since they are clearly used. Headbomb {t · c · p · b} 19:26, 27 October 2017 (UTC)

Standardization. At one time or another, all of the 50ish no-longer-supported parameters listed at the top of Module:Citation/CS1/Whitelist were used. Some have gone away because their functionality has been replaced, some have gone away because they had non-standard form – capitalized, camelCase, ... This group is (I think) the last of the non-standard-form parameter names.

BRFAs aren't very problematic. One of my requests was speedily approved seven or so days after the request. In the mean time another editor had added some code to AWB general fixes so by the time I got my approval, there was no need to run that bot task so it never did. This, I think, is a similar case; add the five parameter names to Wikipedia:AutoWikiBrowser/Rename template parameters and let all of those editors who run AWB with general fixes turned on, do the fix for us.

—Trappist the monk (talk) 19:53, 27 October 2017 (UTC)

I have added these five parameters to the citation, cite book, cite journal, cite news, and cite web sections of Wikipedia:AutoWikiBrowser/Rename template parameters. They will also accumulate in Category:CS1 errors: deprecated parameters.

—Trappist the monk (talk) 18:11, 29 October 2017 (UTC)

I support the removal of these five non-standard aliases as well.

However, after going through the whitelist, shouldn't we add support for hyphenated aliases of at least some of these parameters to fully adhere to the RfC?

• |network=
• |newsgroup=
• |newspaper=
• |inset=
• |postscript=
• |vauthors=
• |veditors=
• |website=

Alternatively, their hyphenated aliases should at least be added to the auto-suggestion list, I think.

--Matthiaspaul (talk) 22:31, 1 November 2017 (UTC)

Network, Newsgroup, Newspaper, Inset, and Postscript are unhyphenated words, not two words jammed together. I would support |web-site=, but I am from the olden times when "website" was a newfangled concoction, and I don't think I have ever seen editors try to use |web-site= on WP. I have no opinion about vauthors and veditors, but I see your point. – Jonesey95 (talk) 00:42, 2 November 2017 (UTC)

I tend to agree with you in regard to the first three params. Postscript and website exists in both forms (although the versions without hyphen are much more common). Ironically, I have occasionally tried to enter the last two forms, not because I'd like them, but just because I did remember that RfC and was too lazy to look up the help for these rarely used parameters... ;-) --Matthiaspaul (talk) 18:16, 2 November 2017 (UTC)

Deprecation follow-up post-implementation

NihlusBOT was able to fix 99+% of pages featuring these four deprecated parameters, and I went through with some regex searches to find and fix a few hundred affected pages. I suspect that there are somewhere between zero and a few hundred pages that slipped through my net somehow, and that they will trickle into the category over the next month or so as the job queue refreshes the affected articles.

I have marked these four parameters as unsupported in the sandbox code, so at the next module update, the parameters will show up in the unsupported parameter category. – Jonesey95 (talk) 17:18, 17 November 2017 (UTC)

Update to the live cs1|2 modules weekend of 4–5 November 2017

I expect to update the live cs1|2 modules some time 4–5 November with these changes:

changes to Module:Citation/CS1

1. support kerning of quotes in wikilinks; discussion
2. fix multiple language categorization bug; discussion
3. single letter/digit 2nd level domain names for .cash TLD; discussion
4. support for |chapter-url-access=; discussion
5. remove trailing separator character from |title=; discussion
6. internationalization of month, season, and named dates; discussion
7. fix broken |trans-title= missing |title= message display; discussion
8. remove url access signal nowrap; discussion
9. allow wikilinks in |vauthors= and |veditors=; discussion
10. mute zwj error message when used with Indic script; discussion

changes to Module:Citation/CS1/Configuration

1. add Tajik to script-title language list;
2. support for |chapter-url-access=;
3. add Gujarati to script-title language list;
4. add missing error handlers for {{bioRxiv}} and {{citeseerx}}; discussion
5. internationalization of month, season, and named dates;

changes to Module:Citation/CS1/Whitelist

1. support for |chapter-url-access=;
2. deprecate |doi_brokendate=, |doi_inactivedate=, |trans_chapter=, |trans_title=, |template doc demo=; discussion

changes to Module:Citation/CS1/Date validation

1. internationalization of month, season, and named dates;

changes to Module:Citation/CS1/Identifiers

1. accept OL prefix in |ol=; discussion
2. |jfm= error checking; discussion
3. |mr= error checking; discussion
4. |zbl= error checking; discussion
5. case insensitive sort; discussion
6. link inactive dois; discussion

changes to Module:Citation/CS1/Utilities

1. is_wikilink() in support kerning of quotes in wikilinks;

changes to Module:Citation/CS1/COinS

1. fix long-time corrupted-metadata bug; discussion
2. preserve author order in COinS output; discussion

—Trappist the monk (talk) 12:20, 29 October 2017 (UTC)

On removing the nowrap for the accesslocks, why don't we just &nbsp; it instead rather than use a non-breaking thin space? We could do this for all identifiers. Headbomb {t · c · p · b} 12:51, 29 October 2017 (UTC)

(edit conflict) – mediawiki still fails to correctly identify edit conflicts

Because it doesn't work. Probably because the css in <cite class="citation"> which applies to all cs1|2 template renderings, includes word-wrap: break-word; and because the locks are images and not words. This is all in the archives of this page.

—Trappist the monk (talk) 14:46, 29 October 2017 (UTC)

I'd just like to say here that I'm really happy to see the "allow wikilinks in vauthors" change. This one has been occasionally but regularly biting me. Thanks! —David Eppstein (talk) 00:56, 2 November 2017 (UTC)

Suggestions for related fixes

I wonder if, due to the fix for vauthors/veditors, whether the problem with page/pages/at can be solved. --Izno (talk) 14:36, 29 October 2017 (UTC)

Perhaps, but now is not the time to be doing new work on the module. After the update.

—Trappist the monk (talk) 15:02, 29 October 2017 (UTC)

Similarly for detecting and reporting wikilinks in author parameters. --Izno (talk) 14:37, 29 October 2017 (UTC)

Wikilinks in author parameters are permissible (even in this perculiar usage):

{{cite book |title=Title |last=[[Abraham Lincoln|Lincoln]] |first=[[Abraham Lincoln|Abraham]]}}

Lincoln, Abraham. Title. {{cite book}}: Check |first= value (help)

'"`UNIQ--templatestyles-000000BF-QINU`"'<cite id="CITEREFLincoln" class="citation book cs1">[[Abraham Lincoln|Lincoln]], Abraham. ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.aulast=Lincoln&rft.aufirst=Abraham&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Check <code class="cs1-code">&#124;first=</code> value ([[Help:CS1 errors#bad_paramlink|help]])</span>

—Trappist the monk (talk) 15:02, 29 October 2017 (UTC)

Permissible in the code, but the documentation has proscribed them since before January 2009. Should we remove the prohibition from the documentation if wikilinks in author/editor/contributor parameters do no harm? The prohibition may have been there due to code that was not sophisticated enough to handle wikilinks. A separate discussion section may be best. – Jonesey95 (talk) 20:22, 29 October 2017 (UTC)

Contributor not with editor instead of author?

There appears to be a bug in the {{cite book}} implementation, which throws an error message "contributor not without author" if no author, but an editor is defined. I think it should work with editors as well, at least I can't think of any valid reason why it shouldn't... --Matthiaspaul (talk) 18:09, 2 November 2017 (UTC)

For clarity, what would be an example of such a reference? I can't think of a reason why you wouldn't be able to use chapter and author instread of contribution and contributor if it's in an edited collection. The contributor is for when the author of a work isn't the author of a part of it, but in an edited collection there is no overall author, so the author field won't be confused with an overall author but rather correctly thought of as the chapter author. Umimmak (talk) 18:38, 2 November 2017 (UTC)

Still, from the viewpoint of contributors there should be no difference between authors and editors. The actual example was:

{{cite book |editor-first=Bernhard |editor-last=Jones |title=Encyclopaedia of photography |contribution=Introduction |contributor-first1=Peter C. |contributor-last1=Bunnell |contributor-first2=Robert A. |contributor-last2=Sobieszek |publisher=Arno Press |date=1974}}

The problem could be worked around by changing the editor into author parameters, by I do not consider this a proper solution. It should be sufficient if at least one author or editor is specified.

--Matthiaspaul (talk) 23:26, 2 November 2017 (UTC)

To clarify, I wasn't suggesting to change the |editor= to |author= since that makes the citation incorrect by saying Jones is the author of the book, not its editor:

{{cite book |author-first=Bernhard |author-last=Jones |title=Encyclopaedia of photography |contribution=Introduction |contributor-first1=Peter C. |contributor-last1=Bunnell |contributor-first2=Robert A. |contributor-last2=Sobieszek |publisher=Arno Press |date=1974}}

Bunnell, Peter C.; Sobieszek, Robert A. (1974). Introduction. Encyclopaedia of photography. By Jones, Bernhard. Arno Press.

Rather, I was proposing changing |contributor= to |author= and |contribution= to |chapter=, i.e.:

{{cite book |editor-first=Bernhard |editor-last=Jones |title=Encyclopaedia of photography |chapter=Introduction |author-first1=Peter C. |author-last1=Bunnell |author-first2=Robert A. |author-last2=Sobieszek |publisher=Arno Press |date=1974}}

Bunnell, Peter C.; Sobieszek, Robert A. (1974). "Introduction". In Jones, Bernhard (ed.). Encyclopaedia of photography. Arno Press.

The same result comes from using Template:Cite encyclopedia, where |contribution= and |chapter= are just alternate names:

{{cite encyclopedia |editor-first=Bernhard |editor-last=Jones |encyclopedia=Encyclopaedia of photography |chapter=Introduction |author-first1=Peter C. |author-last1=Bunnell |author-first2=Robert A. |author-last2=Sobieszek |publisher=Arno Press |date=1974}}

{{cite encyclopedia |editor-first=Bernhard |editor-last=Jones |encyclopedia=Encyclopaedia of photography |contribution=Introduction |author-first1=Peter C. |author-last1=Bunnell |author-first2=Robert A. |author-last2=Sobieszek |publisher=Arno Press |date=1974}}

Bunnell, Peter C.; Sobieszek, Robert A. (1974). "Introduction". In Jones, Bernhard (ed.). Encyclopaedia of photography. Arno Press.

Although I suppose it's inconsistent with the lack of quotation marks for contributions in authored works as opposed to edited works... Umimmak (talk) 00:58, 3 November 2017 (UTC)

I see, but my intend wasn't to cite from a chapter named Introduction specifically, but just to name the contributors as contributors (because, IIRC, the book made some fuzz about it on the sleve). Just like I would indicate the contribution of an artist for his sketches included in a book. --Matthiaspaul (talk) 10:15, 3 November 2017 (UTC)

Oh, well if you're not actually citing the Introduction, just saying the book has an introduction and you think that's important to specify or whatever, that's what |other= is for, so something like:

{{cite book |editor-first=Bernhard |editor-last=Jones |title=Encyclopaedia of photography |others=Introduction by Peter C. Bunnell & Robert A. Sobieszek |publisher=Arno Press |date=1974}}

Jones, Bernhard, ed. (1974). Encyclopaedia of photography. Introduction by Peter C. Bunnell & Robert A. Sobieszek. Arno Press.

Although I don't think it's necessary to specify the book has an introduction by someone else in most cases if you're not actually citing the introduction itself. Umimmak (talk) 10:54, 3 November 2017 (UTC)

This citation?

The purpose of a citation is to identify the source that supports text in Wikipedia articles. In this case particularly to attribute the source of the quote that is part of the citation. I think that the quote can be found in Cassell's 1911 at Sensitometry so that would indicate that the reprint has little or no relevance in this particular reference; all the more so because it is not the purpose of Wikipedia in general, and citations in particular, to promote any source no matter how much fuzz the publisher put on the sleeve.

I might rewrite Cassell's 1911 like this:

{{cite book |editor-first=Bernhard Edward |editor-last=Jones |section=Sensitometry |title=Cassell's Cyclopaedia of Photography |publisher=Cassell |location=London |date=1911 |section-url=https://archive.org/stream/cassellscyclopae00jone#page/472/mode/2up |pages=472 et seq}}

Jones, Bernhard Edward, ed. (1911). "Sensitometry". Cassell's Cyclopaedia of Photography. London: Cassell. pp. 472 et seq.

For the reprint, I agree with Editor Umimmak. It is not necessary to name an introduction's authors if you are not citing the introduction. To me, it is not necessary to include the 1974 reprint at all. But, if it is to be included, it should specifically include the in-source location (page, section title, etc) of the text that supports the article's text (or quotation).

—Trappist the monk (talk) 11:54, 3 November 2017 (UTC)

message-id error

I've been trying to wrap my head around what causes an error in

• uw-beave!jim (April 2, 1983). "Re: program to separate xlisp distribution files". Newsgroup: net.sources. Usenet: bnews.uw-beave.451. Retrieved March 27, 2017. {{cite newsgroup}}: Check |message-id= value (help)

|message-id= doesn't have < > characters. I'm not sure what "make sure that it contains @ between left and right identifiers" mean however, but |message-id=@bnews.uw-beave.451@ doesn't work. Headbomb {t · c · p · b} 12:31, 3 November 2017 (UTC)

@Headbomb: I think it means that the parameter should be of the form |message-id=foo@bar, rather like an email address - foo being the left identifier, and bar being the right. --Redrose64 🌹 (talk) 23:39, 3 November 2017 (UTC)

@Redrose64: so how do we fix the above? Headbomb {t · c · p · b} 01:36, 4 November 2017 (UTC)

No idea. --Redrose64 🌹 (talk) 08:53, 4 November 2017 (UTC)

In case anyone here is unaware, the format for message-id parameters comes from RFC 822. According to that format, the given message-ID is definitely invalid (it should look like an email address with a string of non-special characters (or a quoted string), an @, and a domain name). But on the other hand, it is the actual message-ID of an actual message. So maybe we shouldn't be so strict about what we demand for this field? —David Eppstein (talk) 07:21, 6 November 2017 (UTC)

Indeed. It is important that the source should be easily and unambiguously verified. The error message creates unnecessary confusion, as this is not a citation formatting error. The validation parameters for this field may be too strict. We shouldn't expect that all of the thousands of RFCs that IETF publishes are followed or applied in all situations. Relax the validation to reflect the real world, and perhaps add in the doc that the format specified in RFC 822 is the preferred one. 72.43.99.138 (talk) 16:10, 6 November 2017 (UTC)

I'm fine with the error being flagged by default, all that needs to be done is have a |ignore-message-ID-error=yes or like we do in case of ISBN errors that are nonetheless the ones that feature on book covers. Headbomb {t · c · p · b} 16:31, 6 November 2017 (UTC)

Any progress on relaxing this overly strict check? That standard was obviously not universally followed; see this message from 1983 which has "bnews.uw-beave.451" as a message-id (451@bnews.uw-beave intended?) -- Michael Bednarek (talk) 02:05, 29 November 2017 (UTC)

I'm not sure how we might relax the test. It works for the 500+ transclusions of {{cite newsgroup}} and adding a special test or exception for this single outlying example seems like a bit of work to little benefit. Until there a lot more examples where this non-standard style of message id is used for messages referenced in article space, I see no real reason to do anything.

At the moment, Category:CS1 errors: message-id is empty so it would appear that someone found a solution to the one example that was categorized.

—Trappist the monk (talk) 11:54, 29 November 2017 (UTC)

That's fine with me. The message mentioned above was used in shar and User:Hecseur sensibly changed |message-id=… to |quote=message-id:…. Cheers, Michael Bednarek (talk) 13:06, 29 November 2017 (UTC)

Yeah, I saw it used that way over in Usenet so I assumed it'd be the best way to deal with it. Hecseur (talk) 15:03, 29 November 2017 (UTC)

Cite book

I am missing the possibility of naming an illustrator. bkb (talk) 16:58, 4 November 2017 (UTC)

|others= ? — Preceding unsigned comment added by Headbomb (talk • contribs)

Indeed, from the documentation: others: To record other contributors to the work, including illustrators. For the parameter value, write Illustrated by John Smith.. --Izno (talk) 17:53, 4 November 2017 (UTC)

Overhaul Template:Cite court

{{Cite court}} is a hard-coded simplistic template, that should probably be folded into the CS1 system.

At bare minimum, it needs to support the following:

• |access-date= and |accessdate= (its doc says it supports the latter, but it does not)
• |archive-url= / |archiveurl=, |archive-date= / |archivedate=, |dead-url= / |deadurl=
• |via= – for URLs that do not go to the reporter but to somewhere less official
• |id= – for reporters that don't fit the US pattern (volume order, etc.); e.g., India uses two reporters, with a different format, which can be done with |id=Something_here; Something2_here (or, see below, we could have a switch for specifying the format)
• |judge= – to use with a judge name or "majority" or whatever, to attribute whatever is in |quote=
• |at= – make the current, weird |poinpoint= an alias to this, and stop "advertising" pinpoint in the doc
• |lang= – we cite cases that are not in English
• |title= – make the current, weird |litigants= an alias to this, and list both in the doc
• |work= – make the current, weird |reporter= an alias to this or vice versa, and list both in the doc
• |page=, |pages= – alias to |at= / |pinpoint=
• |volume= – template presently only supports |vol=
• Ensure that |reporter= / |work= will work properly and not generate a bogus URL if people use this as freeform text, e.g. post an entire Indian reporter citation (or both of them) into it. Not ideal, but our templates are here to serve editors and readers, not make them serve our templates.
• Re-doc |vol= and |opinion= as only pertaining to US case citations (and those that follow the same format); optionally, just code in various differ formats and provide a switch for them, thought that would be a lot of work (e.g. the two India don't use the same order of citation parts).
• I think there's some code in this thing that auto-builds URLs to US case archives if all the right bits are filled in. That's convenient for US cases, but broken otherwise.
• Various other parameters we don't use constantly might also be desirable to add; the above are the ones I care about.

 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  15:10, 7 November 2017 (UTC)

To be part of CS1, it has to follow established style elements for common/related parameters. It seems that the template cites a court opinion. What are the correct mappings between the parameters that CS1 uses and this template's parameters?

Am I correct in assumming

|court= equivalent to |author= (or |publisher=?)

|opinion= equivalent to |work=

|date= equivalent to |publication date=

etc. etc.

Two obvious inconsistencies:

|quote= output is in parentheses

|court= output is also in parentheses

24.105.132.254 (talk) 21:12, 7 November 2017 (UTC)

I'm of two thoughts on this topic. The first is that we could just cite court opinions in the established CS1 style as if they're articles published in a specific volume of a journal (the reporter). However, this would mean that the titles of cases would be rendered in quotation marks, and not italics. CMOS doesn't convert court citations in that way; it parrots the established Bluebook style to cite cases, so there's precedent for us to do so as well. I agree with the basic premise that we should upgrade the template to bring it up to modern citation standards (access dates, archive-url/archive-date, etc) and use the standard parameter names. Imzadi 1979 → 22:10, 7 November 2017 (UTC)

{{cite book |title=Parker v. D.C. |volume=478 <!--|reporter=F.3d--> |page=401 <!--|at=370 -->|last=Silberman |publisher=D.C. Cir. |date=2007 |url=http://pacer.cadc.uscourts.gov/docs/common/opinions/200703/04-7041a.pdf |quote=As such, we hold it unconstitutional.}}}}

Silberman (2007). Parker v. D.C. (PDF). Vol. 478. D.C. Cir. p. 401. As such, we hold it unconstitutional.

{{cite book |title=Parker v. D.C. |volume=478 <!--|reporter=F.3d--> |page=401 <!--|at=370 --> |publisher=D.C. Cir. |date=2007 |url=http://pacer.cadc.uscourts.gov/docs/common/opinions/200703/04-7041a.pdf |quote=As such, we hold it unconstitutional.}}

Parker v. D.C. (PDF). Vol. 478. D.C. Cir. 2007. p. 401. As such, we hold it unconstitutional.

Doesn't seem so bad. --Izno (talk) 00:32, 8 November 2017 (UTC)

Right. But here is a different rendition:

{{cite web |title=04-7041a | id=Parker v. D.C. |department=Opinions |website=U.S. Court of Appeals for the D.C. Circuit |date=9 March 2007 |last=Silberman |url=http://pacer.cadc.uscourts.gov/docs/common/opinions/200703/04-7041a.pdf |quote=As such, we hold it unconstitutional.}}

Silberman (9 March 2007). "04-7041a" (PDF). Opinions. U.S. Court of Appeals for the D.C. Circuit. Parker v. D.C. As such, we hold it unconstitutional.

The above cites a webpage that contains the opinion (in pdf file format), not the opinion itself. 65.88.88.126 (talk) 18:57, 8 November 2017 (UTC)

Not for our purposes; that's an official copy; the URL is a convenience link. We'd use |via= if it didn't come from an official source; already covered this in the original post.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  11:23, 9 November 2017 (UTC)

There are lots of legal citation styles, and they're all inconsistent. Bluebook is a US style, and not the only one (though the dominant one). WP doesn't ape everything CMoS does, and its editors' rationales are not ours. It is pretty much universally accepted that legal case names go in italics, and that's fine; just use an alternate version of the title parameter that does that instead of quotation marks. Yes, we should treat court as equivalent to |publisher=. |opinion= isn't |work=; |reporter= is. Yes, quotation marks should be in quotation marks not parentheses, or no one is going to understand they're quotations. If there's strident demand to mimic Bluebook and other citation styles exactly we can add a switch to do that, as we're already doing with Vancouver, but it's probably a lot of work so absent an RfC indicating a solid consensus to require it be done, I would suggest not going there (unless someone has a lot of time on their hands). I have to observe that we have loads of legal articles, even on important cases like FCC v. Pacifica and Reno v. ACLU, that make no use of {{Cite court}}; it's actually quite disused. So, I'll be highly skeptical of any argument that diverging from its present output is somehow against consensus.

Another option is to just leave this template mostly alone, and create a new one at {{Cite case}} (presently a redirect that would have to be usurped after bot replacement) that is CS1-based from the start, and normalizes all the citation style to match {{cite journal}}. Someone can continue using the current few-featured template, which is really only for US cases, if they demand to do so (i.e., per WP:CITEVAR) if consensus on an article's talk page doesn't override them to prefer the better-featured and more consistent template. Regardless, there should be a CS1 template for citing cases, that is jurisdiction-agnostic. The simplest way to do this is probably to have |id= hold the compressed citation gobbledegook that no one understands but lawyers in particular legal systems, e.g. |at=438 U.S. 726 – treat it like |doi=, |isbn=, or any other "ID code" parameter – and use normal parameters to present the information readable, for mere mortals, e.g. |work=United States Reports, etc. I suppose we can already "fake it" with {{Cite journal}}, but it would be nice to have an explicitly legal variant, documented for that context, that supported aliases like |reporter= and |court=. Maybe this can just be done as a template wrapper that uses {{Cite journal}}.
 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  11:23, 9 November 2017 (UTC)

{{Bluebook journal}} and {{Bluebook website}}. I would oppose any move to make the cs1|2 templates conform to Bluebook style. cs1|2 have assumed their own style, I see no need to add a switch to [mimic Bluebook]; we did that experiment with MLA which produced spaghetti code – since removed.

Glad you finally got to the wrapper-/meta-template solution. There are some. See Category:Citation templates that wrap CS1 templates and Category:Citation Style 1 meta-templates. (It isn't clear to me why there are two categories that hold more-or-less the same sort of stuff; any know what distinguishes meta- from wrapper-templates?)

—Trappist the monk (talk) 12:02, 9 November 2017 (UTC)

It seems that the most cs1 templates adhere to the following style:

• the source (|work= → |reporter=) is emphasized via italics
• a named section within the source (|title= |chapter= |article=, etc. → |opinion=) is distinguished via quotation marks

It makes more sense to me to bring court citations that use cs1 into alignment with cs1 rather than the other way around. 65.88.88.69 (talk) 21:01, 9 November 2017 (UTC)

please separate translation tables into /i18n subpage

Please separate translation tables from Module:Citation/CS1/Configuration into /i18n subpage, so that it can has its own block policy, and make maintenance task easy when copied to local wiki, especially when updating the changed configuration. --Ans (talk) 10:30, 8 November 2017 (UTC)

I think that makes no sense to me. /Configuration exists in large part for internationalization. All of these tables would need to move:

• messages
• aliases
• special_case_translation
• defaults
• date_names
• keywords
• maint_cats
• prop_cats
• title_types
• error_conditions
• id_handlers

That's most of /Configuration.

—Trappist the monk (talk) 11:34, 8 November 2017 (UTC)

That's just half of /Configuration, not most. --Ans (talk) 00:45, 9 November 2017 (UTC)

What? How do you figure that? /Configuration is currently 1130 lines. Take away the tables I listed and /Configuration shrinks to about 200 lines. By my calculation, moving 900 lines is most of /Configuration.

—Trappist the monk (talk) 01:32, 9 November 2017 (UTC)

There're 21 tables, your listed table are just 11. However, the size doesn't matter. Translations should have its own block policy. --Ans (talk) 03:05, 9 November 2017 (UTC)

What does "block policy" mean? It is not a phrase that I have seen, ever. How or why is it relevant? To whom? I presently agree with Trappist, not least because you are not explaining your need very well (and jumped straight to implementation). --Izno (talk) 05:16, 9 November 2017 (UTC)

We can quibble about what constitutes just half and most of /Configuration if you would like, but in the end, you are asking us to make a change for you without having offered much in the way of a good reason for us to do the work for you. Without you convince us that we should do the work, I think that the work will not get done.

—Trappist the monk (talk) 10:47, 9 November 2017 (UTC)

I can do the work by myself, if the page is not blocked. I really not prefer asking you to do work for me, but the page is blocked, so I have not much choices.

--Ans (talk) 14:29, 9 November 2017 (UTC)

We do have Module:Citation/CS1/Configuration/sandbox which, at the moment, is identical to the live module. But, you still haven't explained why this change is necessary. You have suggested that the problem is block policy and that your desired solution will make maintenance task easy when copied to local wiki. I think that you mean the protection policies at wikis other than en.wiki and that your phrase block policy means something akin to en.wiki's WP:PROTECT. If that is the problem, why not just change the /Configuration protection level at the 'local' wiki? It is after all, the prerogative of each wiki to establish its own protection rules for their copies of these modules.

—Trappist the monk (talk) 14:58, 9 November 2017 (UTC)

Request to add EThOS id as a parameter for use in cite thesis?

Hello, I'd like to request that the EThOS id was added as a parameter for use in Template:Cite thesis. There are nearly 500,000 PhD theses in the E-Theses Online Service (EThOS) and it would be good to cite them properly. Examples include

• Stephen Hawking:
  • Hawking, Stephen William (1966). Properties of Expanding Universes. repository.cam.ac.uk (PhD thesis). University of Cambridge. doi:10.17863/CAM.11283. OCLC 62793673. EThOS uk.bl.ethos.601153
• Brian Cox:
  • Cox, Brian Edward (1998). Double diffraction dissociation at large momentum transfer (PDF). desy.de (PhD thesis). University of Manchester. OCLC 644443338. EThOS uk.bl.ethos.675409
• Richard Dawkins:
  • Dawkins, Richard Clinton (1966). Selective pecking in the domestic chick. bodleian.ox.ac.uk (DPhil thesis). University of Oxford. EThOS uk.bl.ethos.710826
• Brian May:
  • May, Brian Harold (2008). A survey of radial velocities in the zodiacal dust cloud (PDF). spiral.imperial.ac.uk (PhD thesis). Imperial College London. Bibcode:2008srvz.book.....M. doi:10.1007/978-0-387-77706-1. hdl:10044/1/1333. ISBN 9780387777054. OCLC 754716941. EThOS uk.bl.ethos.443586
• ... and nearly 500,000 others indexed by the British Library

As of 8 November 2017 these can only be added as a seperate identifer outside the cite thesis template e.g.

<ref name=dawkins>{{cite thesis |degree=DPhil |first=Richard Clinton|last=Dawkins |title=Selective pecking in the domestic chick |publisher=University of Oxford |date=1966 |url=http://solo.bodleian.ox.ac.uk/OXVU1:LSCOP_OX:oxfaleph020515491 |website=bodleian.ox.ac.uk}} {{EThOS|uk.bl.ethos.710826}}</ref>

Having them included in cite thesis would allow the following (neater) citation style:

<ref name=dawkins>{{cite thesis |degree=DPhil |first=Richard Clinton|last=Dawkins |title=Selective pecking in the domestic chick |publisher=University of Oxford |date=1966 |url=http://solo.bodleian.ox.ac.uk/OXVU1:LSCOP_OX:oxfaleph020515491 |website=bodleian.ox.ac.uk| EThOS=uk.bl.ethos.710826}}</ref>

As of 8 November 2017 the latter citation style gives Unknown parameter |EThOS= ignored for example: Dawkins, Richard Clinton (1966). Selective pecking in the domestic chick. bodleian.ox.ac.uk (DPhil thesis). University of Oxford. {{cite thesis}}: Unknown parameter |EThOS= ignored (help)

Pinging @Andrew Davidson: and @Mike Peel: for information, Thanks Duncan.Hull (talk) 22:29, 8 November 2017 (UTC)

You can currently use the |id= parameter like so:

<ref name=dawkins>{{cite thesis |degree=DPhil |first=Richard Clinton|last=Dawkins |title=Selective pecking in the domestic chick |publisher=University of Oxford |date=1966 |url=http://solo.bodleian.ox.ac.uk/OXVU1:LSCOP_OX:oxfaleph020515491 |website=bodleian.ox.ac.uk| id={{EThOS|uk.bl.ethos.710826}}}}</ref>

Dawkins, Richard Clinton (1966). Selective pecking in the domestic chick. bodleian.ox.ac.uk (DPhil thesis). University of Oxford. EThOS uk.bl.ethos.710826.

P.S. I love seeing Brian May in such good company! – Jonesey95 (talk) 00:19, 9 November 2017 (UTC)

If we were to do this, the parameter name would be |ethos=; cs1|2 doesn't do mixed case parameter names. In all of the examples here, the identifier includes uk.bl.ethos. Why? Does ethos have other, for lack of a better term, prefixes? This request looks to me like the request we recently had about creating a google-books id. That didn't go anywhere.

—Trappist the monk (talk) 11:18, 9 November 2017 (UTC)

the full id includes the prefix uk.bl.ethos., maybe they'll add new prefixes later (its future proof). Also, Google isn't a National library so the British Library can't be usefully compared with it @Trappist the monk:. The workaround of id={{EThOS|uk.bl.ethos.710826}} will be ok as an interim solution Duncan.Hull (talk) 10:17, 10 November 2017 (UTC)

Overhaul Template:Academic peer reviewed

Haven't looked at it in detail, but it doesn't even do basic stuff like support |first1=|last1=, etc., only a single monolithic |author=, and it seems to be missing various other basic "modern" WP citation template features.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  09:50, 9 November 2017 (UTC)

Documentation lacking and the documentation page buggered up (should be an all green background), but internally that template uses {{cite journal}} and |vauthors= so that part of cs1|2 would seem to be ok. It duplicates the url from one of |doi= or |pmid= in |url= which amounts to overlinking. The template also misuses definition list markup for pseudo-headings.

—Trappist the monk (talk) 11:01, 9 November 2017 (UTC)

<shaking fist> Definitely needs some work. I guess the forcing of |vauthors= is easy to undo, as are the missing parameters and the bad markup. I guess this question is whether to have it continue to be such a wrapper, with fixes, or its own real template calling the CS1 module. The former is easier though less "elegant" I suppose.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  11:27, 9 November 2017 (UTC)

I would suggest that the proper venue for discussion of this template is really its own talk page. Because the template was created by Editor Doc James, whose primary work at en.wiki is, I think, the realm of WP:MED, and because WP:MED apparently has a preference for Vancouver author style, that is why Editor Evolution and evolvability used |vauthors= when the {{cite journal}} template was added.

—Trappist the monk (talk) 12:26, 9 November 2017 (UTC)

Happy to see the template improved. Editing templates is not my strength. Doc James (talk · contribs · email) 12:29, 9 November 2017 (UTC)

Why such a complicated template? Why not just do something like

{{Academic peer reviewed |journal=Journal of Foobar |review=https://... |citation= {{cite journal|vauthors=...}} }}

This way you have citation style flexibility, and don't have to worry about maintaining this as yet another citation template. Headbomb {t · c · p · b} 14:12, 9 November 2017 (UTC)

Hi, I'm happy to help out in any way I can (given that the original template is largely my mess!). However, I'm not very familiar with how to implement CS1 elements, which is why I bodged it together using parameters like |vauthors= that were easy to implement. I'd be thrilled to see it overhauled to use more modern syntax and properly conform with CS1. T.Shafee(Evo&Evo)^talk 11:33, 14 November 2017 (UTC)

Protected edit request on 9 November 2017

Could it be explained in the documentation that magazines with a two-month date range should be hyphenated? Example: August/September 1996 should be written as August-September 1996. The current system gives an error when you input a date with a forward slash, although this is the industry standard format (at least in the USA). I had to search through the talk archives to figure out a hyphen was required.

Actually, it would be helpful if the cite template would accept a date with a slash between two months anyway, since most people won't notice it gives an error much less track down the template to find out how to fix it. A hyphen makes sense when it spans three months, ie October-December 2012, but it's not very intuitive otherwise, and people are most likely to simply copy/paste from the source (see example) and move on their way. —Мандичка^YO 😜 00:05, 10 November 2017 (UTC)

 Not done

Template documentation is not protected.

—Trappist the monk (talk) 00:11, 10 November 2017 (UTC)

The documentation links to Help:Citation Style 1#Dates, and the "check date" error message help link goes to Help:CS1 errors#bad date. In both of those locations, text explains that dashes should be used for ranges and that hyphens or slashes in ranges are not valid (per MOS:DATERANGE). – Jonesey95 (talk) 00:22, 10 November 2017 (UTC)

Then how do I access the template documentation to edit it? This edit does not have the text that is displayed on the page. I'm assuming it's using an embedded module or template from somewhere else. —Мандичка^YO 😜 00:30, 10 November 2017 (UTC)

{{csdoc}} controls most of the parameter-level documentation for all of the cs1|2 templates so remember that when you edit it with one particular template in mind your changes cascade to the other 20-ish templates.

—Trappist the monk (talk) 00:36, 10 November 2017 (UTC)

Please fix the Template:Cite book/doc for us?

I provided a quick fix, by adding a horizontal scroll bar to table in section Template:Cite_book/doc#TemplateData but it's only temporary. As I stated in my edit summary: → currently about 30% of this table disappears without a trace behind the right-hand edge of the standard-size monitor screen. Thanks, Poeticbent talk 19:43, 14 November 2017 (UTC)

That is the so-called documentation for visual editor. There are some of us who have been chastised for touching it so those same some-of-us are reluctant to touch it again. Were I king, I would delete the thing; alas, I am not. Perhaps take your complaint to Wikipedia:VisualEditor/Feedback or Wikipedia talk:TemplateData.

—Trappist the monk (talk) 20:54, 14 November 2017 (UTC)

What I did, didn't work anyway, because my revision was NOT transcluded into the Template:Cite book. The fatal error in its display stays all the same. This is hopeless. Poeticbent talk 21:16, 14 November 2017 (UTC)

You might trim the work aliases list. I don't know why it includes "journal", "website", "newspaper", "magazine", and "mailinglist".

—Trappist the monk (talk) 21:37, 14 November 2017 (UTC)

@Poeticbent: After amending the doc page, did you WP:NULLEDIT the template? This is essential for VE to pick up a doc revision; a WP:PURGE updates the display of the doc page in the template, but apparently doesn't pass it on to VE. --Redrose64 🌹 (talk) 23:20, 14 November 2017 (UTC)

The template data section does not need to be particularly human readable in the documentation page. Its main intent is to be used when using visual editor. So in some sense it does not really matter if it looks weird in the documentation page.

Furthermore the TemplateData section does not need to be part of the documentation page. En wiki seems to have arrived on this convention, other projects differ. There are some templates like Template:Collapse top which has the template data section in a separate page Template:Collapse top/TemplateData which is included in the <noinclude> of the main template. It might be an idea to do that here if the page width is a real problem.

What should not be done is editing the templatedata section just to make it look good in the documentation page.

There is a bigger problem with templates which have a great many aliases. Citation templates are particularly bad for this. I think its worth a phabricator bug, so that developers can do something to improve display on documentation pages and within visual editor. --Salix alba (talk): 23:38, 14 November 2017 (UTC)

I've now created a phabricator task T180542. --Salix alba (talk): 23:54, 14 November 2017 (UTC)

I think you mean "some fields have a great many aliases", not "some fields have a great many parameters". --Redrose64 🌹 (talk) 00:37, 15 November 2017 (UTC)

Salix alba, if you have the skills to put this fragile, syntax-sensitive template data programming code somewhere other than the template's documentation page, please do so. I have been verbally abused for editing template data code, so I don't touch it anymore. – Jonesey95 (talk) 02:50, 15 November 2017 (UTC)

Done.--Salix alba (talk): 06:10, 15 November 2017 (UTC)

• Thanks for the help Salix alba, but the actual display error has yet to be cleared. Please take a look at Template:Cite_book#TemplateData. The same mess which brought me here in the first place, is still there to be fixed, hopefully via T180542. Thanks, Poeticbent talk 06:32, 15 November 2017 (UTC)

I've now put it into a {{collapse top}} section. You need never look at it again, and it fixes the page width problem unless you expand the collapsed section. This output is not really made for human consumption, probably only of interest for people who are tuning the template data information. For those they will have to live with the output until the bug gets fixed. --Salix alba (talk): 09:23, 15 November 2017 (UTC)

A use case for journal citations with no titles

The citation templates complain when they are given a journal article with no title. It is not that a title is needed for them to be able to format it, but rather that they are built with the assumption that everything has a title and that omitting a title is a mistake. But sometimes it is not a mistake. The case I'm regularly running across is that I am making lists of published reviews of academic books. Almost all the reviews have something resembling the same title as each other, one that would be pointless to repeat each time and that would clutter the citation even to write out in full a single time, something like:

Predicting Recidivism Using Survival Models, by Peter Schmidt and Ann Dryden Witte. New York: Springer-Verlag, 1988. 174 pp. $39.00 cloth.

(that's not a citation itself, it's the title of the review). Even JSTOR doesn't give this as the title; instead it lists it as

Reviewed Work: Predicting Recidivism Using Survival Models. by Peter Schmidt, Ann Dryden Witte

(something that never actually appears in that form in the journal that published the review). It would work to give the title of the reviewed book as the title of the review, and in some cases (like JSTOR 2074102, the one I'm copying this from) one could then add a |department=Reviews to make it clear that it's a book review, but my preference would be to omit the title altogether and instead put something like "Reviews of [book title]" above the start of the list of the reviews. Unfortunately, that is not currently possible with these templates. Is there some way to make it possible? —David Eppstein (talk) 05:27, 15 November 2017 (UTC)

I've tried asking about this before: [1]. It isn't ideal, but what I've been doing is just |title=[Review of Work], though sometimes reviews have real titles you'd want to cite in addition to saying what the reviewed work is (see the examples in my message above). Umimmak (talk) 05:44, 15 November 2017 (UTC)

Wouldn't |title=none accomplish what you're trying to achieve if you don't want to show any title? Headbomb {t · c · p · b} 06:13, 15 November 2017 (UTC)

Land, Kenneth C. (March 1989). Contemporary Sociology. 18 (2): 245–246. JSTOR 2074102.{{cite journal}}: CS1 maint: untitled periodical (link)

Huh. Works. Next time I should try reading the docs. [searches for "none" on Help:CS1, doesn't find anything relevant] Maybe the docs need updating to mention this? —David Eppstein (talk) 06:30, 15 November 2017 (UTC)

Yeah, it's not documented. It should be. Headbomb {t · c · p · b} 11:44, 15 November 2017 (UTC)

It would work to give the title of the reviewed book as the title of the review, and in some cases (like JSTOR 2074102, the one I'm copying this from) one could then add a |department=Reviews to make it clear that it's a book review, but my preference would be to omit the title altogether.

I believe that is the correct way to cite this (with |department=Reviews included). I believe that most people will search for an item's review by the item's title, and formatting the citation as suggested in the quote above will make it immediately understandable. A list of reviews with the same title may be visually jarring, but semantically is the way to go. You are citing different works (journal reviews) by different authors (reviewers). It seems to me you are asking for a |title-mask= parameter. 24.105.132.254 (talk) 18:54, 15 November 2017 (UTC)

Why do you think people are going to search for the reviews I list, when I also provide links for them to go to the review directly without searching? Why do you think it will be difficult to figure out the title of the reviewed work, when I am giving it at the top of the list of reviews? Why do you think searching for the title of the reviewed work will give a correct exact match for the title of the review? And why do you think providing more semantically-accurate metadata should take a higher priority than avoiding making things jarring for readers? A |title-mask= parameter would also work, but would also require me to make up a title for a review that often doesn't have a real title (the block at the top of the review giving the title of the reviewed work is not really the title of the review). Incidentally, if you want to see many more examples of |title=none, check out maintenance category Category:CS1 maint: Untitled periodical (which tracks this usage); there are currently around 500 articles in there. —David Eppstein (talk) 07:36, 19 November 2017 (UTC)

Spurious ISSN error warning?

On my draft User:Jo-Jo Eumerus/Lake Suguta one of the citations is creating an ISSN error, but apparently the ISSN link still works. Jo-Jo Eumerus (talk, contributions) 15:11, 19 November 2017 (UTC)

X not x; like it says in the help text.

—Trappist the monk (talk) 15:28, 19 November 2017 (UTC)

Sure, but why is that an error if it still works? Jo-Jo Eumerus (talk, contributions) 15:59, 19 November 2017 (UTC)

Because the standard @ §2.1 Construction of ISSN says:

"An ISSN consists of eight digits. These are the Arabic numerals 0 to 9, except that an upper case X can sometimes occur in the final position as a check digit."

Works because WorldCat have chosen to remap that ISSN to an OCLC identifier.

—Trappist the monk (talk) 16:18, 19 November 2017 (UTC)

Fixed. Use an uppercase X. Headbomb {t · c · p · b} 22:59, 19 November 2017 (UTC)

Worldcat sometimes maps invalid ISSNs to publications. – Jonesey95 (talk) 00:08, 20 November 2017 (UTC)

Semicolon with single author and "et al."

Using the {{cite web}} template, should there be a semicolon in a reference starting "Nuss, M.; et al. ..."? Example at this permalinked page. In regular English we wouldn't say "Nuss, M.; and others". Am I understanding this correctly? Can the semicolon be removed?  SchreiberBike | ⌨  18:09, 22 November 2017 (UTC)

AFAICT, there are only two editors for that page, it reads: "[editors: Landry, B., Nuss, M.]", so I'm not sure why the et al. is necessary. FWIW, CMOS17 reads

• [§14.76] For works with more than ten authors—more common in the natural sciences—Chicago recommends the policy followed by the American Naturalist (see bibliog. 5): only the first seven should be listed in the bibliography, followed by et al. (Where space is limited, the policy of the American Medical Association may be followed: up to six authors’ names are listed; if there are more than six, only the first three are listed, followed by et al.)
• [§6.20] The abbreviation et al. (et alia [neut.], et alii [masc.], or et aliae [fem.], literally “and others”), whether used in regular text or (more often) in bibliographical references, should be treated like etc. If et al. follows a single item, however (e.g., “Jones et al.”), it requires no preceding comma.
• [§6.60] When items in a series themselves contain internal punctuation, separating the items with semicolons can aid clarity.

It's just a bit weird because there's only one editor before the "et al." but the semicolon makes sense if it's preceded by multiple names I think. Umimmak (talk) 19:17, 22 November 2017 (UTC)

This page lists their authors as "Nuss, M., B. Landry, R. Mally, F. Vegliante, A. Tränkner, F. Bauer, J. Hayden, A. Segerer, R. Schouten, H. Li, T. Trofimova, M. A. Solis, J. De Prins & W. Speidel". I couldn't find "[editors: Landry, B., Nuss, M.]". Et al. seemed appropriate rather than listing all 14. I tried listing them all and using |display-authors=1, but that has the same problem with the semicolon. I suppose I could use |display-authors=2 or some other number, then it would make sense to have the semicolon. It's a frequently used reference on Wikipedia and making the list as long as Chicago suggests above seems excessive.  SchreiberBike | ⌨  19:45, 22 November 2017 (UTC)

I couldn't find "[editors: Landry, B., Nuss, M.]" FWIW, Landry and Nuss were the editors involved for the Pseudocatharylla faduguella entry (I'd link it but this website doesn't seem to have permalinks? Umimmak (talk) 20:23, 22 November 2017 (UTC)

Thanks. I see now. Since it's impossible to link to individual pages in that database I thought the longer list was more appropriate.  SchreiberBike | ⌨  20:32, 22 November 2017 (UTC)

The single-author plus "et al." form should NOT be used in a full citation, as that is incomplete characterization of the source and its authorship. (It also suggests that the editor was too lazy to list at least three more authors, which validly raises a question of whether anything else has been scamped.) In all cases at least the first four authors should be listed (four, because that is where {harv} automatically switches to the "et al." form), and display-authors to three or more. Any less short changes the reader, and suggests a certain sloppiness.

As I recall, the recommended form for truncating a long list of authors in a full citation is "and N others" (where "N" is the appropriate number). In this regard the action of display-authors is incorrect. Use of "et al." is only for short cites, like "Smith, et al., 2000". Note the use of the comma; I believe the semicolon is incorrect here. ~ J. Johnson (JJ) (talk) 21:12, 22 November 2017 (UTC)

One author + et al. is a valid citation style, not laziness. Listing 3 authors out of 234 vs 1 out of 234 makes no difference. Headbomb {t · c · p · b} 21:25, 22 November 2017 (UTC)

By default, the CS1 templates separate author names with semicolons. Authors' first and last names are separated by commas. For display options, see #Display options. – Jonesey95 (talk) 22:20, 22 November 2017 (UTC)

Bullshit. "234" is a strawman argument, and even a red-herring, as I am NOT talking about entering 234 authors. I am talking about as many as four. If some editor can't take the trouble to list just that many they are undercutting WP:V, and showing a lack of due care and effort.

Yes, "one author + et al. is valid citation style", but only in the context of a short citation (short cite), such as "Smith, et al., 2000". Which should connect to a full citation, which contains the full bibliographic details, such as co-authors (up to some reasonable number), along with the authors' first names or initials. (Note that, for short cites, two authors + et al. is also acceptable, where the single author and year is ambiguous.)

Jonesey, are you paying attention? (I will go back and highlight portions of my prior comment to make it clearer.) Of course cs1 separates the authors by semicolons, and uses a comma where each author's surname is inverted from the rest of that individual author's name. That is the standard and accepted form for full citations, and I have said nothing contrary to that. Where the semicolon is incorrect is in short citations, where only the surnames (last names) are used. ~ J. Johnson (JJ) (talk) 23:35, 22 November 2017 (UTC)

No, one author + et al is a valid style for 'long/full' citations as well. There's absolutely no reason for why the n in author-n has to exceed a certain value before display the et al., it makes zero difference if you list the first 4 authors of 200, or the first author of 200. Some style guides say list 3 before the et al., others say list 6, and yet others say list 1. Headbomb {t · c · p · b} 01:16, 23 November 2017 (UTC)

Where "one author + et al." is considered valid for a full citation is in various journals where space is reckoned expensive. In the same context they also routinely abbreviate titles, which is something we do not do here, space not being limited.

You say "There's absolutely no reason for why the n in author-n has to exceed a certain value", but that is false. There is a very good reason to include at least four authors: so that cs1 and harv can do their CITEREF magic. Another even better reason is that many authors write more than one co-authored article in a year, and leaving out all the coauthors can make it harder to find the right article. There is also a good reason for listing all co-authors (well, up to a dozen or so): senior researchers often put their names at the end (so that their co-authors can have more credit), or alphabetization may put a very notable contributor well down the list, and shorting the list of authors means that people familiar with the subject might not recognize the significance of the contributors. ~ J. Johnson (JJ) (talk) 23:01, 25 November 2017 (UTC)

No CS1/harv/CITEREF magic depends on what the N of truncation is. Which of

• Aaij, R.; et al. (LHCb Collaboration) (April 2011). "Observation of J/ψp Resonances Consistent with Pentaquark States in Λ0b→J/ψK−p Decays". Physics Letters B. 698 (2): 115–122. doi:10.1016/j.physletb.2011.03.006.
• Aaij, R.; Adeva, B.; Adinolfi; et al. (LHCb Collaboration) (April 2011). "Observation of J/ψp Resonances Consistent with Pentaquark States in Λ0b→J/ψK−p Decays". Physics Letters B. 698 (2): 115–122. doi:10.1016/j.physletb.2011.03.006.
• Aaij, R.; Adeva, B.; Adinolfi, M.; Adrover, C.; Affolder, A.; Ajaltouni; et al. (LHCb Collaboration) (April 2011). "Observation of J/ψp Resonances Consistent with Pentaquark States in Λ0b→J/ψK−p Decays". Physics Letters B. 698 (2): 115–122. doi:10.1016/j.physletb.2011.03.006.
• Aaij, R.; Adeva, B.; Adinolfi, M.; Adrover, C.; Affolder, A.; Ajaltouni, Z.; Albrecht, J.; Alessio, F.; Alexander, M.; Alvarez Cartelle, P.; Alves, A.A.; Amato, S.; Amhis, Y.; Amoraal, J.; Anderson, J.; Appleby, R.B.; Aquines Gutierrez, O.; Arrabito, L.; Artuso, M.; Aslanides, E.; Auriemma, G.; Bachmann, S.; Bailey, D.S.; Balagura, V.; Baldini, W.; Barlow, R.J.; Barschel, C.; Barsuk, S.; Bates, A.; Bauer, C.; Bauer, Th.; Bay, A.; Bediaga, I.; Belous, K.; Belyaev, I.; Ben-Haim, E.; Benayoun, M.; Bencivenni, G.; Bernet, R.; Bettler, M.-O.; van Beuzekom, M.; Bifani, S.; Bizzeti, A.; Bjørnstad, P.M.; Blake, T.; Blanc, F.; Blanks, C.; Blouw, J.; Blusk, S.; Bobrov, A.; Bocci, V.; Bondar, A.; Bondar, N.; Bonivento, W.; Borghi, S.; Borgia, A.; Bos, E.; Bowcock, T.J.V.; Bozzi, C.; Brambach, T.; van den Brand, J.; Bressieux, J.; Brisbane, S.; Britsch, M.; Britton, T.; Brook, N.H.; Brown, H.; Büchler-Germann, A.; Bursche, A.; Buytaert, J.; Cadeddu, S.; Caicedo Carvajal, J.M.; Callot, O.; Calvi, M.; Calvo Gomez, M.; Camboni, A.; Camilleri, L.; Campana, P.; Capon, G.; Carbone, A.; Carboni, G.; Cardinale, R.; Cardini, A.; Carson, L.; Carvalho Akiba, K.; Casse, G.; Cattaneo, M.; Charles, M.; Charpentier, Ph.; Chiapolini, N.; Cid Vidal, X.; Clark, P.J.; Clarke, P.E.L.; Clemencic, M.; Cliff, H.V.; Closier, J.; Coca, C.; Coco, V.; Cogan, J.; Collins, P.; Constantin, F.; Conti, G.; Contu, A.; Coombes, M.; Corti, G.; Cowan, G.A.; Currie, R.; DʼAlmagne, B.; DʼAmbrosio, C.; Da Silva, W.; David, P.; De Bonis, I.; De Capua, S.; De Cian, M.; De Lorenzi, F.; De Miranda, J.M.; De Paula, L.; De Simone, P.; Decamp, D.; Degaudenzi, H.; Deissenroth, M.; Del Buono, L.; Deplano, C.; Deschamps, O.; Dettori, F.; Dickens, J.; Dijkstra, H.; Dima, M.; Diniz Batista, P.; Donleavy, S.; Dossett, D.; Dovbnya, A.; Dupertuis, F.; Dzhelyadin, R.; Eames, C.; Easo, S.; Egede, U.; Egorychev, V.; Eidelman, S.; van Eijk, D.; Eisele, F.; Eisenhardt, S.; Eklund, L.; dʼEnterria, D.G.; Esperante Pereira, D.; Estève, L.; Fanchini, E.; Färber, C.; Fardell, G.; Farinelli, C.; Farry, S.; Fave, V.; Fernandez Albor, V.; Ferro-Luzzi, M.; Filippov, S.; Fitzpatrick, C.; Fontanelli, F.; Forty, R.; Frank, M.; Frei, C.; Frosini, M.; Fungueirino Pazos, J.L.; Furcas, S.; Gallas Torreira, A.; Galli, D.; Gandelman, M.; Gandini, P.; Gao, Y.; Garnier, J.-C.; Garofoli, J.; Garrido, L.; Gaspar, C.; Gauvin, N.; Gersabeck, M.; Gershon, T.; Ghez, Ph.; Gibson, V.; Gligorov, V.V.; Göbel, C.; Golubkov, D.; Golutvin, A.; Gomes, A.; Gordon, H.; Grabalosa Gándara, M.; Graciani Diaz, R.; Granado Cardoso, L.A.; Graugés, E.; Graziani, G.; Grecu, A.; Gregson, S.; Gui, B.; Gushchin, E.; Guz, Yu.; Gys, T.; Haefeli, G.; Haines, S.C.; Hampson, T.; Hansmann-Menzemer, S.; Harji, R.; Harnew, N.; Harrison, P.F.; He, J.; Hennessy, K.; Henrard, P.; Hernando Morata, J.A.; van Herwijnen, E.; Hicheur, A.; Hicks, E.; Hofmann, W.; Holubyev, K.; Hopchev, P.; Hulsbergen, W.; Hunt, P.; Huse, T.; Huston, R.S.; Hutchcroft, D.; Iakovenko, V.; Iglesias Escudero, C.; Ilten, P.; Imong, J.; Jacobsson, R.; Jahjah Hussein, M.; Jans, E.; Jansen, F.; Jaton, P.; Jean-Marie, B.; Jing, F.; John, M.; Johnson, D.; Jones, C.R.; Jost, B.; Kapusta, F.; Karbach, T.M.; Keaveney, J.; Kerzel, U.; Ketel, T.; Keune, A.; Khanji, B.; Kim, Y.M.; Knecht, M.; Koblitz, S.; Konoplyannikov, A.; Koppenburg, P.; Kozlinskiy, A.; Kravchuk, L.; Krocker, G.; Krokovny, P.; Kruse, F.; Kruzelecki, K.; Kucharczyk, M.; Kukulak, S.; Kumar, R.; Kvaratskheliya, T.; La Thi, V.N.; Lacarrere, D.; Lafferty, G.; Lai, A.; Lambert, R.W.; Lanfranchi, G.; Langenbruch, C.; Latham, T.; Le Gac, R.; van Leerdam, J.; Lees, J.-P.; Lefèvre, R.; Leflat, A.; Lefrançois, J.; Leroy, O.; Lesiak, T.; Li, L.; Li, Y.Y.; Li Gioi, L.; Lieng, M.; Liles, M.; Lindner, R.; Linn, C.; Liu, B.; Liu, G.; Lopes, J.H.; Lopez Asamar, E.; Lopez-March, N.; Luisier, J.; Mʼcharek, B.; Machefert, F.; Machikhiliyan, I.V.; Maciuc, F.; Maev, O.; Magnin, J.; Maier, A.; Malde, S.; Mamunur, R.M.D.; Manca, G.; Mancinelli, G.; Mangiafave, N.; Marconi, U.; Märki, R.; Marks, J.; Martellotti, G.; Martens, A.; Martin, L.; Martin Sanchez, A.; Martinez Santos, D.; Massafferri, A.; Mathe, Z.; Matteuzzi, C.; Matveev, M.; Matveev, V.; Maurice, E.; Maynard, B.; Mazurov, A.; McGregor, G.; McNulty, R.; Mclean, C.; Meissner, M.; Merk, M.; Merkel, J.; Merkin, M.; Messi, R.; Miglioranzi, S.; Milanes, D.A.; Minard, M.-N.; Monteil, S.; Moran, D.; Morawski, P.; Morris, J.V.; Mountain, R.; Mous, I.; Muheim, F.; Müller, K.; Muresan, R.; Murtas, F.; Muryn, B.; Musy, M.; Mylroie-Smith, J.; Naik, P.; Nakada, T.; Nandakumar, R.; Nardulli, J.; Nedos, M.; Needham, M.; Neufeld, N.; Nicol, M.; Nies, S.; Niess, V.; Nikitin, N.; Oblakowska-Mucha, A.; Obraztsov, V.; Oggero, S.; Okhrimenko, O.; Oldeman, R.; Orlandea, M.; Ostankov, A.; Pal, B.; Palacios, J.; Palutan, M.; Panman, J.; Papanestis, A.; Pappagallo, M.; Parkes, C.; Parkinson, C.J.; Passaleva, G.; Patel, G.D.; Patel, M.; Paterson, S.K.; Patrick, G.N.; Patrignani, C.; Pavel-Nicorescu, C.; Pazos Alvarez, A.; Pellegrino, A.; Penso, G.; Pepe Altarelli, M.; Perazzini, S.; Perego, D.L.; Perez Trigo, E.; Pérez-Calero Yzquierdo, A.; Perret, P.; Petrella, A.; Petrolini, A.; Pie Valls, B.; Pietrzyk, B.; Pinci, D.; Plackett, R.; Playfer, S.; Plo Casasus, M.; Polok, G.; Poluektov, A.; Polycarpo, E.; Popov, D.; Popovici, B.; Potterat, C.; Powell, A.; du Pree, T.; Pugatch, V.; Puig Navarro, A.; Qian, W.; Rademacker, J.H.; Rakotomiaramanana, B.; Raniuk, I.; Raven, G.; Redford, S.; Reece, W.; dos Reis, A.C.; Ricciardi, S.; Rinnert, K.; Roa Romero, D.A.; Robbe, P.; Rodrigues, E.; Rodrigues, F.; Rodriguez Cobo, C.; Rodriguez Perez, P.; Rogers, G.J.; Romanovsky, V.; Rouvinet, J.; Ruf, T.; Ruiz, H.; Sabatino, G.; Saborido Silva, J.J.; Sagidova, N.; Sail, P.; Saitta, B.; Salzmann, C.; Sambade Varela, A.; Sannino, M.; Santacesaria, R.; Santinelli, R.; Santovetti, E.; Sapunov, M.; Sarti, A.; Satriano, C.; Satta, A.; Savrie, M.; Savrina, D.; Schaack, P.; Schiller, M.; Schleich, S.; Schmelling, M.; Schmidt, B.; Schneider, O.; Schopper, A.; Schune, M.-H.; Schwemmer, R.; Sciubba, A.; Seco, M.; Semennikov, A.; Senderowska, K.; Serra, N.; Serrano, J.; Shao, B.; Shapkin, M.; Shapoval, I.; Shatalov, P.; Shcheglov, Y.; Shears, T.; Shekhtman, L.; Shevchenko, O.; Shevchenko, V.; Shires, A.; Simioni, E.; Skottowe, H.P.; Skwarnicki, T.; Smith, A.C.; Sobczak, K.; Soler, F.J.P.; Solomin, A.; Somogy, P.; Soomro, F.; Souza De Paula, B.; Spaan, B.; Sparkes, A.; Spiridenkov, E.; Spradlin, P.; Stagni, F.; Steinkamp, O.; Stenyakin, O.; Stoica, S.; Stone, S.; Storaci, B.; Straumann, U.; Styles, N.; Szczekowski, M.; Szczypka, P.; Szumlak, T.; TʼJampens, S.; Talanov, V.; Teodorescu, E.; Terrier, H.; Teubert, F.; Thomas, C.; Thomas, E.; van Tilburg, J.; Tisserand, V.; Tobin, M.; Topp-Joergensen, S.; Tran, M.T.; Tsaregorodtsev, A.; Tuning, N.; Ukleja, A.; Urquijo, P.; Uwer, U.; Vagnoni, V.; Valenti, G.; Vazquez Gomez, R.; Vazquez Regueiro, P.; Vecchi, S.; Velthuis, J.J.; Veltri, M.; Vervink, K.; Viaud, B.; Videau, I.; Vilasis-Cardona, X.; Visniakov, J.; Vollhardt, A.; Voong, D.; Vorobyev, A.; Vorobyev, An.; Voss, H.; Wacker, K.; Wandernoth, S.; Wang, J.; Ward, D.R.; Webber, A.D.; Websdale, D.; Whitehead, M.; Wiedner, D.; Wiggers, L.; Wilkinson, G.; Williams, M.P.; Williams, M.; Wilson, F.F.; Wishahi, J.; Witek, M.; Witzeling, W.; Wotton, S.A.; Wyllie, K.; Xie, Y.; Xing, F.; Yang, Z.; Ybeles Smit, G.; Young, R.; Yushchenko, O.; Zavertyaev, M.; Zhang, L.; Zhang, W.C.; Zhang, Y.; Zhelezov, A.; Zhong, L.; Zverev, E. (April 2011). "Observation of J/ψp Resonances Consistent with Pentaquark States in Λ0b→J/ψK−p Decays". Physics Letters B. 698 (2): 115–122. doi:10.1016/j.physletb.2011.03.006.

to use is a matter that the template should be neutral on. The first is the standard way of citing things in particle physics, while last three are definitely non-standard.Headbomb {t · c · p · b} 04:09, 26 November 2017 (UTC)

More bullshit. And as before, a strawman argument, as NO ONE – other than YOU, that is – has suggested a need to list 200+ coauthors, let alone 546. Once again you have mistaken what I said. (Sigh, guess I needed to highlight my "up to a dozen or so".) Your little exercise demonstrates a level of WP:POINTiness to be lamented in one who aspires to adminship. And my three reasons still beats your "absolutely no reason". ~ J. Johnson (JJ) (talk) 06:17, 26 November 2017 (UTC)

The point, which you refuse to hear, is that "Aiij, R.; et al. (2011) ..." is entirely fine in 'long citation' form, and is both used on Wikipedia's featured articles (e.g. Quark) and in the published world, and I will oppose any attempt at legitimizing this citation style, per WP:CITEVAR. This style in no way suggests that an editor who uses it "was too lazy to list at least three more authors" nor does it "validly raises a question of whether anything else has been scamped". Headbomb {t · c · p · b} 13:56, 26 November 2017 (UTC)

I have given my reasons, which you have not addressed other than to deny. As you seem rather over-wrought for discussion, there is little point in continuing. ~ J. Johnson (JJ) (talk) 22:43, 26 November 2017 (UTC)

It is claimed no CS1/harv/CITEREF magic depends on what the N of truncation is: when short citations are in use, with templates like {{harvnb}}, and the full citation has more than four authors, at least the first four surnames are necessary in order to create a valid link between the two templates. --Redrose64 🌹 (talk) 23:43, 26 November 2017 (UTC)

Yes. ~ J. Johnson (JJ) (talk) 21:37, 27 November 2017 (UTC)

Use of {{harv}} is not required, and you can easily accomodate it if you insist on having {{harv}} around. (Aaij et al. 2011) works just fine, e.g., if you combine it with {{harvid|Aaij et al.|2011}}. Headbomb {t · c · p · b} 13:48, 2 December 2017 (UTC)

Attempting to restate the original question

Wow, that went sideways. I believe that SchreiberBike was asking a more generic question, which was: Should the punctuation in a citation using CS1 style (i.e. full citations) be "Smith, Alfred; et al." or "Smith, Alfred et al."? In other words, should there be a semicolon, something else, or any punctuation at all, between a single author's name and "et al.", and does CS1 allow an editor to make that choice? Perhaps SchreiberBike can let us know if that was the initial query. – Jonesey95 (talk) 03:09, 23 November 2017 (UTC)

@Jonesey95: Indeed. If we weren't using Latin, we could say "Smith, Alfred and others", but that way we are not using paired commas to set off the first name used last. We could say "Smith, Alfred, and others", but that could be confused with one person named Smith and another named Alfred; though it doesn't look like that if we write "Smith, A. and others". On reflection, I'm thinking that the semicolon "Smith, A.; and others" is the best choice. It's also the way the template works.  SchreiberBike | ⌨  03:29, 23 November 2017 (UTC)

I think that a semicolon here is the least bad choice (among semicolon, comma, or nothing), as SchreiberBike lays out above. And when more than one author is listed before "et al.", a semicolon is essentially performing the function of a serial comma, a stylistic choice that, in this case, reduces ambiguity. – Jonesey95 (talk) 03:53, 23 November 2017 (UTC)

It might be noted that Science uses a comma to separate authors, but then it does not invert the surname, so there is no confusion. Nature does invert, and uses the comma for both that and separating authors, but there is (or should be?) no confusion with dual use of the comma as they use initials. But where ever there is a list of authors, with inverted first names (such as here at WP), yes, it is preferable to use both comma and semicolon for (resp.) name inversion and author separation. My complaint here (above) is not with the semicolon, but with the use of "et al." to avoid listing co-authors in the full citation, as implied in the examples. ~ J. Johnson (JJ) (talk) 23:06, 25 November 2017 (UTC)

Thank you for the helpful clarification. It appears that your complaint is with editors and editing guidelines, then, not with the Citation Style 1 templates. It has been my experience that changing editors and editing guidelines is much more challenging than changing templates. – Jonesey95 (talk) 23:28, 25 November 2017 (UTC)

It was initially about templates because OP was asking about turning off the semicolon if only one author is listed before the "et al.", although I agree with J. Johnson in that this should never happen so it shouldn't be encouraged by the template. Umimmak (talk) 23:45, 25 November 2017 (UTC)

Indeed. I have generally found templates (etc.) to be much better behaved. Though I allow my first encounter with List-defined references was pretty wild. And there was an encounter with a self-modifying program once, but I've pretty much forgotten about that. ~ J. Johnson (JJ) (talk) 23:53, 25 November 2017 (UTC)

Archive-date parameter

Moved from Wikipedia:Village pump (technical) § Archive-date parameter

I was just wondering whether the |archive-date= function could be performed automatically with links to the Internet Archive, by interpreting the URL. For example:

https://web.archive.org/web/20160303181922/http://www.historyhome.co.uk/c-eight/ministry/northmin.htm.

As the date is already included in the URL, might it be possible to code {{cite web}} so that |archive-date= appears automatically? Thanks.--Nevé–selbert 19:09, 23 November 2017 (UTC)

I believe that InternetArchiveBot does this for you if you go to the page's history and click Fix Dead Links. I haven't tried it, though. – Jonesey95 (talk) 19:18, 23 November 2017 (UTC)

@Jonesey95: that's good, but what I'm asking is whether the parameter can be done away with entirely, with Internet Archive links.--Nevé–selbert 20:07, 23 November 2017 (UTC)

I've often wondered this myself. The only concern would be how to format the date, if we want consistency either of this field within an article or consistency of date fields within the cite. DMacks (talk) 20:11, 23 November 2017 (UTC)

mdy probably should be the default. For dmy or ymd formatting, |dmy-all= or |ymd-all= should be used per {{Cite web#Date}}.--Nevé–selbert 20:34, 23 November 2017 (UTC)

Help talk:Citation Style 1 is the best forum for discussing changes to the CS1 templates that use |archive-date=. – Jonesey95 (talk) 21:36, 23 November 2017 (UTC)

I am not averse to it. Should user entry be suppressed in favor of auto entry or the other way around? 72.43.99.138 (talk) 15:58, 24 November 2017 (UTC)

There are at least 20 web archiving services in use on enwiki and not all URL types support 14-digit snapshot dates in the URL. -- GreenC 02:34, 27 November 2017 (UTC)

But some do (or at least one of the popular ones does), and it's trivial to detect those that are known to based on other parts of the URL. DMacks (talk) 11:49, 5 December 2017 (UTC)

This is true. Like when I wrote {{webarchive}}, if |date= is missing (equivalent to |archivedate= in the CS1) it will attempt to extract the date from the URL. However |date= is still a required argument so rather than issue a red warning message (since the template is able to display a date) it silently adds it to tracking category. It's fairly trivial for a bot to fix them by adding a |archivedate=, and my bot WP:WAYBACKMEDIC does it already (fix #3). Consider though if editors assume the |archivedate= is optional, they may habitually not add it even with URL's that don't use a 14-digit format. -- GreenC 14:49, 5 December 2017 (UTC)

Hi there GreenC, do you think something similar could work in this scenario? I suppose we could add a red warning message in cases where an editor forgoes |archivedate= with URLs that don't use the 14-digit format. I think |date= should be optional for IA links, but recommended for other archive websites.--Nevé–selbert 10:34, 11 December 2017 (UTC)

Suppress automatic "ed." when adding edition information

Often the "edition" of a book is more than just "Nth ed." Right now if I want to cite the edition which calls itself the "Ninth edition with a revised supplement" (distinct from the "Ninth edition"), it automatically puts "ed." at the end, when it oughtn't.

• Liddell, Henry George; Scott, Robert, eds. (1996). A Greek–English Lexicon. Revised and augmented by Henry Stuart Jones, with Roderick McKenzie et al. (9th ed. with a rev. suppl. ed.). Oxford: Oxford University Press. ISBN 978-0-19-864226-8. {{cite encyclopedia}}: Missing or empty |title= (help)

I suppose I could put it in the title, as in:

• Liddell, Henry George; Scott, Robert, eds. (1996). A Greek–English Lexicon With a Revised Supplement. Revised and augmented by Henry Stuart Jones, with Roderick McKenzie et al. (9th ed.). Oxford: Oxford University Press. ISBN 978-0-19-864226-8. {{cite encyclopedia}}: Missing or empty |title= (help)

And this is probably what I'll end up doing and I guess this works, but I don't think one can just put it in the |title=. It seems like there ought to be like a | or something like that when dealing with these and similar cases.

Umimmak (talk) 09:07, 24 November 2017 (UTC)

Why not:

• Liddell, Henry George; Scott, Robert, eds. (1996). A Greek–English Lexicon. Revised and augmented by Henry Stuart Jones, with Roderick McKenzie et al. (9 with revised supplement ed.). Oxford: Oxford University Press. ISBN 978-0-19-864226-8. {{cite encyclopedia}}: Missing or empty |title= (help)

--Izno (talk) 13:12, 24 November 2017 (UTC)

9 with revised supplement ed. just seems incredibly awkward to me; it's not really how English works, is it? But I guess it is another option. Umimmak (talk) 19:51, 24 November 2017 (UTC)

Please add parameter ZDB for the German public "ZeitschriftenDatenBank"

See http://zdb-opac.de/LNG=EN/DB=1.1/ and from now on http://zdb-katalog.de/?lang=EN of the DFG-funded online German periodicals catalogue. The ZDB-ID allows to access directly all records of the periodical, which is useful since there are often quite different periodicals which have or had the same name. The number should be translated in a http request for the periodicals record as in the simple template in the German language wikipedia. If possible, the value of the LNG parameter in the call to the ZDB could be dependent on the language of the Wikipedia from which the cite journal is being called. Thanks in advance! --L.Willms (talk) 12:54, 24 November 2017 (UTC)

From the ZDB-Website:

Zeitschriftendatenbank (ZDB)
The ZDB: what it is
The ZDB is the world's largest specialized database for serial titles (journals, annuals, newspapers etc., incl. e-journals).
The ZDB: what it contains
The ZDB [currently] contains more than 1.8 million bibliographic records of serials from the 16th century onwards, from all countries, in all languages, held in 3.700 German and Austrian libraries, with 15.6 million holdings information. It does not contain contents, i. e. journal articles.

---

The responsibility for the maintenance and further development of the ZDB lies with the Staatsbibliothek zu Berlin - Preußischer Kulturbesitz and the German National Library.

Request to change CS1 errors: dates

Could Category:CS1 errors: dates please be removed from pages in the Wikipedia space? I don't think it's appropriate to "fix" many of those pages (e.g. anything in Wikipedia:Articles for deletion discussions) Thanks! GoingBatty (talk) 23:20, 26 November 2017 (UTC)

I think this is the original discussion that led to most Talk namespaces having the error categories removed. That was four years ago, so it might be time to revisit, now that many error categories have been added and many are regularly cleaned out. (Of the 44 CS1 error categories, 33 are regularly or occasionally emptied by gnomes.) – Jonesey95 (talk) 04:23, 27 November 2017 (UTC)

@Jonesey95: It's been four years?!?!? Wow - time flies! I haven't been keeping up with the date cleanup (or discussions) lately, but spent some time over the last few days. There are 1,176 Wikipedia-space pages in Category:CS1 errors: dates (3.6% of the category). Thanks! GoingBatty (talk) 03:54, 29 November 2017 (UTC)

I guess I don't see why, in the majority of cases, these pages can't be fixed. Why not create an awb script to add |no-cat=true to the offending cs1|2 templates? No visible change to the archives and the archives no longer clutter the category.

—Trappist the monk (talk) 12:32, 30 November 2017 (UTC)

Is there a description somewhere for what |no-cat= does? I can't find it in {{Citation Style documentation}}.   ~ Tom.Reding (talk ⋅dgaf)  14:17, 30 November 2017 (UTC)

Alias of |template-doc-demo=; it's easier to type (and, for the usage I described above, more semantically correct).

—Trappist the monk (talk) 14:28, 30 November 2017 (UTC)

{{Citation Style documentation/url}} updated (the only place I found with a dedicated section to |template-doc-demo=.   ~ Tom.Reding (talk ⋅dgaf)  15:42, 30 November 2017 (UTC)

Running a script is only a one-time solution, the category will re-clutter (over what timeframe I don't know), and the script would be subject to re-coding for updated error-rules each time it is run, all more complicated (I assume) than creating a mask. Would an article-mask for ignoring Wikipedia:-space pages produce a lot of computational overhead or some other undesirable effect?   ~ Tom.Reding (talk ⋅dgaf)  15:42, 30 November 2017 (UTC)

All of what you wrote is true. But, if we are worried about re-cluttering, then we should do away with categorization entirely. But, we aren't worried about that; look at Category:CS1 errors: deprecated parameters. It was empty before the last module update, after which it filled up with several thousand articles, was cleared by a bot and some gnomes, so that today it has a handful of entries. This Wikipedia namespace thing would be much the same. Any change to the module suite has the possibility of creating new errors that must be fixed – that is inherent in a 'living' encyclopedia.

Tweaking the module to inhibit error categorization for Wikipedia namespace is relatively simple. But, WP: namespace is not solely 'archives' nor is it solely discussion pages, so I think that even in 'talk-like' WP: namespace pages, errors should be fixed (except when the discussion is about the error – probably rare). If we leave WP: namespace pages alone and could somehow magically clear all other errors right now, we would have 5+ category-pages of broken WP: namespace page names that could stay there forever (and by doing so be a plague to future gnomes).

Were a 'one-time script' for AWB, or some other semi-automated tool, to be written, its source might be stored in some public sub-page of Help:CS1 errors or Help:Citation Style 1 with a link from either or both of those pages so that future editors can easily find, update, and use it when the need arises, if the need arises.

—Trappist the monk (talk) 17:06, 30 November 2017 (UTC)

Date formatting

I was surprised to recently learn that it is acceptable MOS to write the date format in two different styles within the same references. Publisher written date and access in digits. Every editor I know picks one style of formatting the date and mainly sticks with it. I see both styles within the same ref so infrequently it was one of the rules of my contest to format dates in one way!♦ Dr. Blofeld 11:50, 29 November 2017 (UTC)

I'm not sure of the purpose of this post. Yes, MOS allows archive and access dates to be in a different format from publication date format and has allowed that for a long time. Date validation in cs1|2 does not look for consistency in different date-holding parameters:

{{cite web |title=Title |publication-date=20 June 1998 |date=August 6, 1977 |url=//example.com |archive-url=//example.org |archive-date=2017-11-29}}

"Title" (published 20 June 1998). August 6, 1977. Archived from the original on 2017-11-29.

So how does your discovery, if I might call it that, apply to us here at WT:CS1? What 'contest'?

—Trappist the monk (talk) 12:05, 29 November 2017 (UTC)

Dr. Blofeld: The MOS text in question is at MOS:DATEUNIFY. If you would like to discuss changing that text, Wikipedia talk:Manual of Style/Dates and numbers is the correct venue. – Jonesey95 (talk) 14:33, 29 November 2017 (UTC)

We could however, check for disallowed mismatches. Like |date=20 August 2009 vs |access-date=August 29, 2013, or silly things like an access-date older than the date. This could even be bot-assisted (e.g. if {{Use dmy dates}} is used, then convert dates to that format).Headbomb {t · c · p · b} 16:43, 29 November 2017 (UTC)

PubMed Identifier on Cite Journal Template

Can an admin change the link(s) to PubMed Identifier (piped in as "PMID") to point directly to PubMed#PubMed identifier (like PMID)? I know the redirect works and all, but it's clearly already piped so it might as well be piped right to the correct spot. This is concerning the Cite Journal template, as well as a few others. Nessie (talk) 18:00, 29 November 2017 (UTC)

I don't think that this is a good idea. The nice thing about the redirect is that the tooltip from the piped redirect matches what the PMID static text means. The direct-linked tooltip just says 'PubMed' which doesn't identify PMID as 'PubMed Identifier'.

—Trappist the monk (talk) 18:41, 29 November 2017 (UTC)

Assuming the tooltip says "PubMed" instead of "PubMed Identifier", I think most people can guess what "ID" stands for. Nessie (talk) 18:58, 29 November 2017 (UTC)

I don't see a reason to change it to a section link, especially since the "What Links Here" results should point to PubMed Identifier since that's the intended link. Headbomb {t · c · p · b} 19:19, 29 November 2017 (UTC)

accessdate (or access-date) and url

I've been involved in a conversation with @Tom.Reding: over an edit he made to Band of Brothers (book); he deleted the entry for accessdate in {{cite book}} because the citation was did not have a url. I acknowledge that he was technically correct because the documentation for cite book states that accessdate requires a url but that information does not appear in the template pop-up available in the editing window. The problem is compounded by the decision to suppress the error message, thereby denying the editor the knowledge of his or her error and the opportunity to correct it. The solution to this is to display the error message. I posting here, btw, because Template talk:Cite book redirected me here.--Georgia Army Vet Contribs Talk 18:01, 2 December 2017 (UTC)

Gaarmyvet, please see the solution on my talk page.   ~ Tom.Reding (talk ⋅dgaf)  18:07, 2 December 2017 (UTC)

No, your solution is to tell a potentially novice editor that he or she has to edit a css page.--Georgia Army Vet Contribs Talk 18:18, 2 December 2017 (UTC)

The error is nothing the reader needs to see and be bothered with, hence why it's suppressed by default, and should remain so. Headbomb {t · c · p · b} 18:24, 2 December 2017 (UTC)

I didn't say "readers." I said "editors."--Georgia Army Vet Contribs Talk 18:51, 2 December 2017 (UTC)

And how exactly do you propose that editors and readers see different things? Headbomb {t · c · p · b} 18:58, 2 December 2017 (UTC)

Well, one option would be to display the error only in preview mode, either the pop-up or the page. It seems to me there are some things that already display only in preview mode, but which slip my mind right now. Of course, every reader is a potential editor.--Georgia Army Vet Contribs Talk 19:42, 2 December 2017 (UTC)

(edit conflict)

There was this rfc, that forced us to turn off a handful of error messages. The supporters of that rfc promised that an automated solution would be forthcoming, and to their credit, I recall that there was some movement toward fulfilling that promise. But, alas, that effort has come to naught. I'm not going to bother to look for the discussions since the rfc where I have suggested that we should lift the restrictions on that handful of error messages, but I will suggest, yet again, that we should, so that human editors can, if they choose, make repairs as they do other editing. Making the error messages visible doesn't guarantee that they will be repaired, but at least exposes the error to the light of day. It has, after all, been more than 4 years and no one has stood up a bot to do as the rfc proponents promised.

The editing tools that you mention are not in our bailiwick here at cs1|2. For issues with them, see Wikipedia:VisualEditor/Feedback and/or MediaWiki_talk:RefToolbar.js; there may be other places to discuss those tools.

—Trappist the monk (talk) 19:50, 2 December 2017 (UTC)

I support displaying all of the error messages. It's been long enough, and no bots have come forward to do the remaining work. (Bots have done much of the work on errors that were initially hidden, like date errors.) – Jonesey95 (talk) 20:05, 2 December 2017 (UTC)

Support showing errors in preview mode, since some fraction of otherwise-error-producing edits will be corrected before even being created, and anyone already in a position to correct will at least be alerted to their existence. Worth doing another RfC imo.   ~ Tom.Reding (talk ⋅dgaf)  22:33, 2 December 2017 (UTC)

I'd prefer always showing errors too, but can concede to a minimum of preview-only depending on the arguments.   ~ Tom.Reding (talk ⋅dgaf)  04:40, 3 December 2017 (UTC)

People regularly miss errors perhaps because they were inattentive, because the error message was outside of the displayed window, because they didn't bother to use the Show preview button, or did but didn't think to look at the page reference section or the reference previews. There are a lot of infoboxes out there that have preview-only-error-messaging. These error messages are regularly ignored – I am guilty of this. I suspect that they are ignored because they don't show at any time but in preview – no motivation for editors to fix the errors. Be glad for gnomes.

There are three error messages (of some 50-ish) that are still hidden. The error messages contribute to these categories (and current page counts):

Category:Pages using citations with accessdate and no URL: 0 articles

Category:Pages using web citations with no URL: 0 articles

Category:Pages using citations with format and no URL: 0 articles

For comparison, Module:Citation/CS1 is currently transcluded in 3,440,000 pages (yeah, that includes pages that aren't categorized so include that fact in your calculations).

—Trappist the monk (talk) 00:12, 3 December 2017 (UTC)

Recently added in 1928 Chico State Wildcats football team:

{{cite news|title=Football Results|newspaper=San Francisco Chronicle|date=October 6, 1928|page=25|via=[[GenealogyBank.com]]|access-date=November 12, 2017}}

The editor intends to signify the newspaper was accessed on November 12, 2017 on the commercial database GenealogyBank.com. Seems reasonable, though not what accessdate means (we don't track offline activities). The warning message would alert users they are doing it wrong and cut down on the number of new instances.

I expect most of them never had a URL for reasons like above, or data entry error forgetting to add. A bot can search the revision history for the original cite and determine there was never a url, it shouldn't be too difficult to fix about 80% (estimate) simply by deleting the url and accessdate. Then rely on the warning messages for the remainder to be fixed manually. -- GreenC 04:18, 3 December 2017 (UTC)

Working on Category:CS1 errors: invisible characters

I know that most of the editors who hang out here are gnomes that prefer to work quietly, but sometimes it's fun to take on a project as a team. This is an invitation to do just that. I'm planning to work on Category:CS1 errors: invisible characters, which has about 3,105 pages in it as of this writing.

I have found that most of the errors are straightforward line feeds and tab characters that should be replaced with spaces. Other characters should be replaced by a dash, apostrophe (single quote mark), space, ellipsis, quote mark, an accented character, or nothing. You can usually figure it out by context, or by checking the original source. I have some regexes that mostly work (each one needs to be checked manually) in the "invisible character" section of User:Jonesey95/AutoEd/unnamed.js, an AutoEd script. You are welcome to copy and refine those regexes, use manual searches, or adopt any other method you want.

I am planning to make a pass through the category to fix the easy errors, then see what's left. Feel free to join me, and post here with questions or comments. – Jonesey95 (talk) 05:56, 3 December 2017 (UTC)

Bot forcing publication titles into the publisher parameter if they're hostnames

FYI

 – Pointer to relevant discussion elsewhere.

Please see User talk:Ohconfucius#Changes to 2017 Brighton siege.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  15:50, 3 December 2017 (UTC)

Help on usage

How would I use this template to cite a death certificate? Or is there a better template for citing primary source documents? -- Foofighter20x (talk) 23:35, 6 December 2017 (UTC)

Which template are you referring to? If you insist on using a CS1 template for death certificates, I would use {{cite report}}. Else, I would go with CS2. In the United States, the publisher would be the relevant vital records office. However, increasingly these authorities consider death certificates private documents, and copies are released only to persons with a proven relationship to the deceased. This may make some or most death certificates non-citable (because the citation would not be verifiable). If you want to cite a death, maybe other, more public sources (newspaper death notices, obituaries, etc.) may be a better option. 72.43.99.146 (talk) 01:22, 14 December 2017 (UTC)

Please add Subtitle parameter for press releases

Hi, I'm adding a {{cite press release}} to an article. Nearly all press releases have a subtitle that gives more information beyond what the title announces. In the one I'm citing,

TerraPass Sells Retail Business, Adopts New Name
Company Reorganizes to Focus on Project Origination in Carbon & Energy

But there's no parameter for this. This has been discussed before but nothing came of it. Adding the subtitle to the title after a colon, as suggested in that discussion, is a non-starter since it is usually a long sentence that would create a two- or more line blue link.. The guidelines for this new parameter would tell editors to only fill in the subtitle if it's relevant to the claim in the article that the citation supports. -- Skierpage (talk) 00:39, 8 December 2017 (UTC)

A colon (or leaving out the subtitle) usually works great. Would you mind linking to an article where you are using this citation to show what it looks like in context? Thanks. – Jonesey95 (talk) 04:26, 8 December 2017 (UTC)

Harvnb links to mixed author/editor cites not working

I'm straying a bit out of my depth here since I normally avoid {{harv}}-type constructs, but is this a feature or a bug?

Template:Harvard citation no brackets#Wikilink to citation does not work's #2.1.1.5 says The citation does not have an author's last name, but the {{harvnb}} link definitely works (search for "Pinowski & Summers-Smith 1990") when only |editor= aliases are used (a minor inconsistency in the /doc), but it doesn't work (search for "Pinowski, Kavanagh & Górski 1991") when 1 author and 2 editors are used.

The mixed author/editor citation was:

* {{cite book |last1=Pinowski |first1=Jan |editor1-last=Kavanagh |editor1-first=P. P. |editor2-last=Górski |editor2-first=W. |title=Nestling mortality of granivorous birds due to microorganisms and toxic substances |year=1991 |publisher=Polish Scientific Publishers |location=Varsovia |isbn=83-01-10476-7|ref=harv}}

and the {{harvnb}} call is (search for "Pinowski, Kavanagh & Górski 1991"):

{{Harvnb|Pinowski|Kavanagh|Górski|1991|pp=111–120}},

which now works, after the citation was changed back to all-authors.

Can {{harvnb}} be made to search for editors when author parameters run out?   ~ Tom.Reding (talk ⋅dgaf)  15:43, 12 December 2017 (UTC)

Could you explain why you want to cite both authors and editors for the same book? Normally, when authors and editors are both present in an instance of a {{cite book}} template, the authors wrote a chapter, and the editors edited the entire book. Jc3s5h (talk) 16:01, 12 December 2017 (UTC)

This isn't meant to be an example for using an author+editor {{harv}} link, but a description of {{harvnb}}s behavior, in what, I assume, can be plausible usage (somewhere).   ~ Tom.Reding (talk ⋅dgaf)  16:11, 12 December 2017 (UTC)

To make the templates understandable and usable, they have some "baked in" concepts of what kind of works exist and what information to cite about them. I don't think trying to work for arbitrary hypothetical cases is at all desirable. Weird citations should be written by hand. Jc3s5h (talk) 16:21, 12 December 2017 (UTC)

If Pinowski is the author and Kavanagh & Górski are the editors, then that is how they should be listed in the cs1|2 template. None of the {{sfn}} and {{harv}}-family of templates will link to a combination of authors+editors so the short citation should be {{Harvnb|Pinowski|1991|pp=111–120}}.

—Trappist the monk (talk) 16:36, 12 December 2017 (UTC)

My original intention was to properly enumerate the author & editor of that citation based on web search. Fortunately, in this case, I was aware of the {{harvnb}} link, but may not in the future (for manual edits anyway, since I now avoid such AWB edits to |ref=harv citations). I could see other editors doing same, but accidentally breaking the link. To have any bit of "fool-proof-ness", it would be good for {{harvnb}} to search for editors when author parameters run out, unless the inability to do so is itself a feature meant to fool-proof some other thing, or at least be much more explicit and verbose about not mixing them (either in the /doc or via a CS1 maint/error message).   ~ Tom.Reding (talk ⋅dgaf)  16:51, 12 December 2017 (UTC)

cs1|2 templates only know what you tell them and they believe you unquestioningly because they cannot know if you are right or wrong and because they can only see what lies between the opening {{ and the closing }}. This same applies to the {{sfn}} and {{harv}} templates. There is no communication between templates, ever (I wish there were). When working with cs1|2 and the {{sfn}} & {{harv}} templates, I have found User:Ucucha/HarvErrors to be invaluable.

Documentation can always be improved so I would encourage you to improve it.

—Trappist the monk (talk) 17:07, 12 December 2017 (UTC)

Ah, I think I see. Because there's no communication, the only way to do this would be for {{Cite book}} to produce 2 #CITEREFs: one for Pinowski only (in my example), and another for Pinowski + the 2 editors, which could become a problem if another source existed where those 3 people are all the authors (or 2 were authors + 1 editor), thus producing 2 or more non-unique anchors.

And thanks for that link; it looks like the harv equivalent for show-all-CS1-errors!   ~ Tom.Reding (talk ⋅dgaf)  18:46, 12 December 2017 (UTC)

@Tom.Reding: There is nothing to prevent you adding as many (or as few) editors as you like to the {{cite book}} template. Editors are ignored by {{harvnb}} and {{sfn}} except when there are no authors in the {{cite book}}. But when {{cite book}} does have authors, the first four need to correspond to those in the {{harvnb}} or {{sfn}}. --Redrose64 🌹 (talk) 18:28, 12 December 2017 (UTC)

If you really have your heart set on doing something unusual with short references, you can use {{harvid}} in the |ref= parameter. Ugly examples here. – Jonesey95 (talk) 05:17, 13 December 2017 (UTC)