Help talk:Citation Style 1

Citation templates (conception)

Citation templates (reality)

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)

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)

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-0000003D-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-0000003F-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)

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

Down to 2,800 at this writing. There is still a lot of low-hanging fruit in this category. – Jonesey95 (talk) 16:40, 24 December 2017 (UTC)

Now at 2773. I basically went after the first page in each alphabetical section (why not?). However, I stumbled across several pages with errors inside non-English text--mostly related to Sri Lanka--which I think will require some work by someone with language skills (example at Cadex 2009). I checked on one editor but he/she has not been here since 2011.--Georgia Army Vet Contribs Talk 20:19, 24 December 2017 (UTC)

Thanks for contributing! I've been skipping those zero-width joiner characters so far, as well as right-to-left text, which does not behave well in my editor. – Jonesey95 (talk) 21:49, 24 December 2017 (UTC)

We recently fixed that issue for several Indic scripts. A bit of Googling seems to show that zwj is also required for Sinhalese so I've added detection for Sinh script to Module:Citation/CS1/Configuration/sandbox (and fixed a bug at the same time):

Cite news comparison

Wikitext	{{cite news|accessdate=2009-10-16|date=2009-10-11|first=Keerthi|language=Sinhala|last=Warnakulasuriya|pages=18|title=යුද රහස් හෙලි කල එන්. ජී. ඕ ක්‍රියාකාරිකයාගේ සුලමුල හෙලිවේ|work=Divaina}}
Live	Warnakulasuriya, Keerthi (2009-10-11). "යුද රහස් හෙලි කල එන්. ජී. ඕ ක්‍රියාකාරිකයාගේ සුලමුල හෙලිවේ". Divaina (in Sinhala). p. 18. {{cite news}}: |access-date= requires |url= (help)
Sandbox	Warnakulasuriya, Keerthi (2009-10-11). "යුද රහස් හෙලි කල එන්. ජී. ඕ ක්‍රියාකාරිකයාගේ සුලමුල හෙලිවේ". Divaina (in Sinhala). p. 18. {{cite news}}: |access-date= requires |url= (help)

—Trappist the monk (talk) 22:04, 24 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)

But perhaps better not to? Tom, when using a short cite (the "Smith and Jones, 2001" construct, not the full bibliographic citation), editors are used only when referring to the whole work, not to any subsections. Sometimes a work is cited by its name, such as for maps or notable reports. But I have never seen any case, nor can I even conceive of (so far), any case where it is necessary or even just useful to cite a combination of author(s) and editor(s). Some times an editor contributes to a section, but then s/he is cited as an author.

The problem here is not in what Harv does or doesn't, or should, but in the basic notion of what you are trying to do. There really isn't any reason for a "combination" author/editor short cite. ~ J. Johnson (JJ) (talk) 21:35, 16 December 2017 (UTC)

Not a journal

A search found some 279 citations referring to "Lecture Notes in XXX" (in most cases from a book series published by Springer) in the journal parameter of the citation [2]. These are not journals and should instead be the |series= parameter of a {{cite book}} or {{cite conference}} citation, with the |title= parameter found and added. Anyone looking for gnome-like edits to perform? Or are any of our bots up to the task? —David Eppstein (talk) 06:54, 16 December 2017 (UTC)

Not {{cite conference}}, as lecture notes generally arise from classes, not conferences. I am dubious about these books of collected lecture notes (I doubt any publisher's editors have spent much time on them, and I am a little amazed at some of the junk Springer publishes), but if that is where a WP editor sees something, then that's what should be cited. However, separate lecture notes are a different matter, the "publication" being questionable. If they are found on a website, then cite as a web site. If found as printed class materials, then consider them as unpublished manuscript. In either case they are of limited reliability. ~ J. Johnson (JJ) (talk) 21:59, 16 December 2017 (UTC)

JSTOR error checking

AFIACT, the allow formats for the jstor identifier are

• All digits
• Same as doi

If error checking could be done, that would be great here. Going to @Trappist the monk: here. Headbomb {t · c · p · b} 22:22, 16 December 2017 (UTC)

Upon browsing, there's a few more formats allowed

• words/dots/numbers
• i#####
• j.foobar

So maybe a simpler check would be |jstor=(\w|\d|\.)+, and verify that the last character isn't a dot. Headbomb {t · c · p · b} 01:21, 17 December 2017 (UTC)

If DOIs are allowed in JSTOR identifiers, then we could reuse the DOI validation code while also allowing values matching the above regex. – Jonesey95 (talk) 01:54, 17 December 2017 (UTC)

DOIs are allowed in JSTOR ids. In my experience these JSTOR documents have the same access requirement as the underlying DOI, which would make use of the JSTOR id an inefficient link. Just use the underlying DOI in such cases. 72.43.99.138 (talk) 15:28, 17 December 2017 (UTC)

I don't think this is always the case. There are journal articles that I can't access directly via the DOI when it goes to the publisher's website, but can access when logged into JSTOR via an institutional account. Furthermore, if you have an individual account with JSTOR (free), you can put some articles that are not externally accessible onto your "shelf" and read them there. Peter coxhead (talk) 16:22, 17 December 2017 (UTC)

metadata dates rfc

RFC: Accurate dates in citation metadata has been closed. So, what to do? We have a decision to do 'something' but that 'something' is wholly undefined. Don't you love decisions like that?

While looking at the code that sets the &rft.date= kv pair I noticed that I had neglected to change the indexing for season dates when I made season indexing compliant to ISO DIS 8601 2016 part 2 §4.7. I have fixed that in the sandbox.

Back to the topic at hand, how it works now:

dates before 1582 produce only the year in the metadata:

{{cite book |title=Title |date=16 March 1581}} → Title. 16 March 1581.

'"`UNIQ--templatestyles-000000AF-QINU`"'<cite class="citation book cs1">''Title''. 16 March 1581.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=1581&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

I suppose that we could refine the demarcation point:

any whole-date before 15 October 1582 gets year only

any month-and-year date before November 1582 gets year only

The 1582–1925 interstice is of course the tough nut. What to do about sources with dates from that period? It might be interesting to create a hidden property category to identify articles with cs1|2 templates with |date= value between 1 October 1582 and 1 January 1926 inclusive. This, I think, would give us an idea of the magnitude of the 'problem' if there is one.

—Trappist the monk (talk) 16:41, 17 December 2017 (UTC)

I've added code to the module sandboxen that will add articles to Category:CS1: Julian–Gregorian interstice when |date= has a value between 1 October 1582 and 1 January 1926 inclusive.

But, if one is to believe this source, the year part of Julian and Gregorian calendars do not diverge (and will not for a long time into either the past or the future). A month-and-year date during the interstice can be either calendar; we can't tell the which and I don't think that we care because both would be represented in the metadata as &rft.date=YYYY-MM.

What we care about are those |date= values that are whole dates, right? When the date is precise to the day it is definitively one calendar or the other and we can't hand-wave it as we can with month-and-year date. These dates then are the problem children so these are the dates that should be categorized. I'll adjust the detector to categorize only these types of dates in the interstice.

—Trappist the monk (talk) 20:22, 17 December 2017 (UTC)

Absent a clear consensus, nothing should be done. These templates exist to standardize the display of information pertinent to verification of articles. If the editor inserted the publication date as identified in the source, then that is enough. The calendaring system used by the source is irrelevant, as far as the templates' purpose is concerned. A reader will be able to replicate the editor's steps and find the particular source, whatever the calendar used. If that reader is a machine (software) with cognition problems is surely not a concern here. It should be a concern of those who tend to that machine. They should be notified, and if the problem persists, the machine should be discarded. AFAIC, I don't see why valuable man-hours should be spent on this external deficiency by people interested in verification. 24.105.132.254 (talk) 20:40, 17 December 2017 (UTC)

I don't know what missing consensus you're talking about. Second paragraph of the closer's comments has this (emphasis mine):

"There is clear and strong consensus that non-Gregorian publication dates should not be fed into COinS, because they will generate inaccurate and misleading data."

The closer specifically did not rule on how the consensus is to be implemented except to say that there is a target goal.

The whole purpose of this topic and any work I do right now is an attempt to understand the extent of the issue and what might be required for us to attain the goal set by the consensus.

—Trappist the monk (talk) 23:30, 17 December 2017 (UTC)

Can't this just be what the original year parameter is used for, with quotation marks / some explanation? e.g., "Some Old Russian Newspaper". 1 March 1700 [19 March 1700 in N.S.] or "Some Old Russian Newspaper". 19 March 1700 [O.S. date listed as "1 March 1700"]. (I can't figure out how to link O.S. and N.S. in the parameter though.Umimmak (talk) 23:57, 17 December 2017 (UTC)

Ellipses being truncated

{{cite web}} seems to be truncating ellipses in citation titles. Examples: 1 2. Opencooper (talk) 15:44, 18 December 2017 (UTC)

It seems that a final full stop/period is always trimmed from the end of the title when rendering the title, which is also a problem when the title ends with an abbreviation such as "U.S.A.". So it would be interesting to understand whether such scenarios were considered when adding the trim logic. Rjwilmsi 16:36, 18 December 2017 (UTC)

Fixed in the sandbox I think:

• {{cite book/new |title=no dots |publisher=Publisher}} → no dots. Publisher.
• {{cite book/new |title=one dot. |publisher=Publisher}} → one dot. Publisher.
• {{cite book/new |title=two dots.. |publisher=Publisher}} → two dots. Publisher.
• {{cite book/new |title=three dots... |publisher=Publisher}} → three dots... Publisher.
• {{cite book/new |title=four dots.... |publisher=Publisher}} → four dots... Publisher.

and, for the Doubting Thomas's, this:

Cite book comparison

Wikitext	{{cite book|publisher=Publisher|title=Title ends with an abbreviation such as "U.S.A.".}}
Live	Title ends with an abbreviation such as "U.S.A.". Publisher.
Sandbox	Title ends with an abbreviation such as "U.S.A.". Publisher.

and take out the quote marks:

Cite book comparison

Wikitext	{{cite book|publisher=Publisher|title=Title ends with an abbreviation such as U.S.A.}}
Live	Title ends with an abbreviation such as U.S.A. Publisher.
Sandbox	Title ends with an abbreviation such as U.S.A. Publisher.

The module does the right thing I think; if it doesn't, no one has ever spoken up about it.

—Trappist the monk (talk) 23:46, 18 December 2017 (UTC)

ASIN

I am seeing evidence that some people are filling in the ASIN reference when there is an ISBN or other identifier. Clearly we should not be using Amazon's proprietary ID unless there is no alternative. What's the best way to document this and perhaps call it out int he interface (ProveIt or whatever) so that people don't use ASIN unless it's required? Guy (Help!) 10:48, 21 December 2017 (UTC)

The documentation already says, Because this link favours one specific distributor, only include it if standard identifiers are not available. It might be reasonable for a maintenance or error message to display on the page when both ASIN and some other set of identifiers (probably ISBN at least) are present. --Izno (talk) 13:44, 21 December 2017 (UTC)

Or the ASIN could automatically be suppressed if ISBN are provided. Headbomb {t · c · p · b} 14:04, 21 December 2017 (UTC)

Because this link favours one specific distributor .. this could be more direct: Because this link favours one company Amazon.com. -- GreenC 14:33, 21 December 2017 (UTC)

No. What you propose is open to misinterpretation, and the documentation could be seen as biased against a specific company. Any company is not targeted; any company that happens to be the distributor in question is. The appearance of neutrality is as important as the thing itself, because people do tend to misread depending on their own biases. No specific company or person (legal or natural) should be mentioned anywhere, even if they are clearly the only example. 72.43.99.138 (talk) 14:53, 21 December 2017 (UTC)

The above needs to be qualified a bit. I suppose it would be ok if any one entity is mentioned in passing, as an example e.g. "such as Amazon". Imo, this would be less likely to be misinterpreted as targeting. 72.43.99.138 (talk) 15:12, 21 December 2017 (UTC)

This is an Amazon-specific link. There is no other entity it could possibly apply to. Headbomb {t · c · p · b} 15:59, 21 December 2017 (UTC)

Correct. Saying "one specific distributor" is an unnecessary obfuscation. Even the IP editor is confused. -- GreenC 19:43, 21 December 2017 (UTC)

I was referring to the documentation, not the identifier. The documentation should avoid the appearance of targeting, even when such interpretation seems far-fetched. There is no confusion on my part at all. The documentation should retain the generic condition ("a specific distributor") and optionally add specific examples ("such as Amazon" − emphasis on plural examples). Both these statements are true, and more neutral than the proposed documentation change. 72.43.99.138 (talk) 15:16, 23 December 2017 (UTC)

"a specific distributor" is the only thing we need to say. "Such as Amazon" is redundant nonsense since this is documentation for the ASIN identifier, and would imply that there are non-Amazon ASINs. Headbomb {t · c · p · b} 20:09, 24 December 2017 (UTC)

8 digit ZBL

I was fixing some citations when I stumbled upon a zbl with 8 digits in Lou van den Dries. It is indeed the valid zbl for the citation in question, but it causes an error because usually zbl appears in nnnn.nnnnn format. As User:Headbomb had pointed out, this is a temporary zbl for new abstracts/articles. He suggested making a maintenance category for these zbls. While I'm not the most experienced editor, since I stumbled upon this, I thought I should bring it to someone's attention. Hecseur (talk) 12:39, 23 December 2017 (UTC)

How to make source-specific shim?

I just embarked on the creation of a source-specific citation template, on the naïve assumption that this would be easy. After all, we're just talking about providing defaults for a few params and passing the rest along to Module:Citation/CS1, right? Right?

Obviously I ran into the wall of my own ignorance pretty quick. So… Any docs on how to create source-specific citation templates based on Module:Citation/CS1? My use case (and, I imagine, most such) just needs to provide defaults for stuff like |publisher=, |editor-last=, |editor-first=. Maybe add some simple logic for creating an URL based on |title= (e.g. prefix |title= with https://en.wikipedia.org/wiki/ and stash it in |url=).

My first cut was using template code that called one of the existing CS1 modules ({{cite_book}} say), but that means I have to write the boilerplate for every single param (last1, last2, last3, etc.) and in MW template syntax. Then I tried just #invoke'ing Module:Citation/CS1, expecting to be able to just touch the params I want to hard code, but here I don't seem to have figured out how to pass stuff from the template to the Lua module (even though using the template seems to pass them just fine).

In other words, I'm completely lost! Help? Surely there's some doc explaining this somewhere? Or an explanation in a talk page archive somewhere (I didn't find anything in the archives here, but that may be my poor choice of terms)? For anyone curious, the project that prompted this plea for help is Template:cite_Grove, an attempt to replace Template:GroveOnline (and its companions) with something that supports all the nice stuff in Module:Citation/CS1 (|ref=harv for one thing!). If you look at its sandbox you can probably tell I'm reduced to voodoo-debugging and trying random variations to get anywhere. Any pointers would be appreciated! --Xover (talk) 14:56, 26 December 2017 (UTC)

Except for the single parameter, |CitationClass=, frame parameters (those parameters implemented in the {{#invoke:}}) are reserved for cs1 debugging.

I can see that {{GroveOnline}} has it's problems, particularly:

|encyclopedia=''In L. Root, Deane.'' [[The New Grove Dictionary of Music and Musicians|Grove Music Online. Oxford Music Online]]

editor's name and static text do not belong there so that line should be replaced with:

|editor-last=Root

|editor-first=Deane L.

|encyclopedia=[[The New Grove Dictionary of Music and Musicians|Grove Music Online. Oxford Music Online]]

The {{subscription required}} template seems to me to be redundant to |url-access=. Perhaps when |url= is not set, only then should {{subscription required}} be executed:

{{#if:{{{url|}}}||{{subscription required}}}}

To support |harv=, add:

|ref={{{ref|}}}

Otherwise, what else is needed?

—Trappist the monk (talk) 16:20, 26 December 2017 (UTC)

Well, |last= etc., since each entry has a separate author (or multiple authors). |doi=, since each entry has a DOI (as does the overall work, I believe). |year=, since there are various publication dates for the entries. There's also a whole collection (7-ish) of Grove templates with duplicated code, variations in quirks and supported params, and so forth. Some call {{cite encyclopedia}} and some {{cite book}}. Some put the entry in |title=, and some in |chapter=.

But do I understand correctly that Module:Citation/CS1's approach is to deliberately force "wrappers" (i.e. source-specific citation templates) to go through existing "core" templates (like {{cite_book}}) rather than invoke the module directly? Are there any docs outlining this anywhere? Any alternate approaches that would let me handle stuff in Lua rather than that horrid mess of line noise that is MW template syntax? --Xover (talk) 17:38, 26 December 2017 (UTC)

|last=, |first=, |doi=, and |year= are all easy fixes that could be made to {{GroveOnline}}.

Before cs1|2 supported |vauthors=, there was (and still is) {{vcite2 journal}} which uses Module:ParseVauthors. {{vcite2 journal}} is a wrapper template that uses its module to convert Vancouver style names to |last=-|first= parameters. The module passes the new author name parameters and everything else that it got from the template-call to Module:Citation/CS1 by calling {{cite journal}} with

frame:expandTemplate{title = 'cite journal', args = citeArgs}

Another example of this trick is {{cite Q}} which uses Module:citeq.

You could do something similar by setting the appropriate default values into a table from the frame and then filling it with whatever is included in the parent frame; parent frame parameters, if set, would, of course, overwrite same-named defaults.

—Trappist the monk (talk) 18:43, 26 December 2017 (UTC)

Perhaps this:

{{Cite Grove/sandbox}} → Sadie, Stanley; Tyrrell, John, eds. (2001). The New Grove Dictionary of Music and Musicians (2nd ed.). London: Macmillan Publishers. ISBN 978-1-56159-239-5. {{cite encyclopedia}}: Missing or empty |title= (help)

Add authors:

{{Cite Grove/sandbox|last=Black |first=A |last2=Brown |first2=B}} → Black, A; Brown, B (2001). Sadie, Stanley; Tyrrell, John (eds.). The New Grove Dictionary of Music and Musicians (2nd ed.). London: Macmillan Publishers. ISBN 978-1-56159-239-5. {{cite encyclopedia}}: Missing or empty |title= (help)

add translator:

{{Cite Grove/sandbox|last=Black |first=A |last2=Brown |first2=B |translator=Green, C}} → Black, A; Brown, B (2001). Sadie, Stanley; Tyrrell, John (eds.). The New Grove Dictionary of Music and Musicians. Translated by Green, C (2nd ed.). London: Macmillan Publishers. ISBN 978-1-56159-239-5. {{cite encyclopedia}}: Missing or empty |title= (help)

uses Module:Sandbox/trappist the monk/cs1 wrapper

If this is what you're looking for, we should move it out of my sandbox and put it somewhere useful.

—Trappist the monk (talk) 22:00, 26 December 2017 (UTC)

Oooh, yes. Provided I'm following this correctly (always an open question ;D), this is exactly what I was looking for! If this is something you're willing to support it should definitely move out of the sandbox; and maybe even amass some "Here's how you make a source-specific citation template in the CS1 system" docs? I don't think most such templates exist as half-baked cut-n-paste code for any reason other than the lack of a better alternative. --Xover (talk) 08:55, 27 December 2017 (UTC)

One point I would make strongly is that, as for all source-specific templates, it's important that they include |mode= and any other parameters needed to enable them to be adapted to the existing style in an article, as per WP:CITEVAR. There have been issues in the past (and indeed ongoing) where source-specific templates only generated CS1 or generated only one format for access and archive dates.

More generally, it's surely a bad idea to call the module directly, rather than via a carefully documented template (such as {{Citation}} or the most appropriate of the "cite" templates). The more entry points there are into a Lua module, the harder it is to maintain and modify (as I know from experience with the automated taxobox system). Peter coxhead (talk) 09:35, 27 December 2017 (UTC)

The templates that use Module:Sandbox/trappist the monk/cs1 wrapper (or whatever its final name becomes) do not have to include |mode=. In {{cite Grove/sandbox}} |mode= does not exist, yet:

{{Cite Grove/sandbox|last=Black |first=A |last2=Brown |first2=B |translator=Green, C |mode=cs2}}

Black, A; Brown, B (2001), Sadie, Stanley; Tyrrell, John (eds.), The New Grove Dictionary of Music and Musicians, translated by Green, C (2nd ed.), London: Macmillan Publishers, ISBN 978-1-56159-239-5 {{cite encyclopedia}}: Missing or empty |title= (help)

This works because the wrapper module passes everything that it gets from the wrapper template to the wrapped template (encyclopedia in this example) which hands them off to Module:Citation/CS1 which knows about |mode= and all other cs1|2 parameters.

—Trappist the monk (talk) 10:04, 27 December 2017 (UTC)

trans-journal

Please add "trans-journal" parameter to Template:cite journal in order to translate foreign journal names into English.--Zoupan 05:56, 28 December 2017 (UTC)

I think script-journal would be useful—perhaps even more useful—since journal titles don't often get translated, but it would be nice to give the actual title and transliteration for titles in non-Latin scripts. Umimmak (talk) 06:33, 28 December 2017 (UTC)

Are the articles referenced in said journals in English? Localized-language sources are preferred for Wikipedia localized editions. A non-local-language in-source article should only be used when 1) it is unique and 2) there are no available reliable translations for it. 72.43.99.146 (talk) 16:02, 28 December 2017 (UTC)