Help talk:Citation Style 1/Archive 38

Page contents not supported in other languages.
Source: Wikipedia, the free encyclopedia.
Archive 35 Archive 36 Archive 37 Archive 38 Archive 39 Archive 40 Archive 45

|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-00000015-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%2FArchive+38" class="Z3988"></span>
Sandbox (not corrupted):
'"`UNIQ--templatestyles-00000017-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%2FArchive+38" 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)

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)

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

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

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

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

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

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

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

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.

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

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.
16:47, 25 October 2017 (UTC)
I wouldn't being favour of it because that means cluttering our articles with virtually pointless ISSNs.
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.
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.
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
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
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
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
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 ) 23:19, 1 November 2017 (UTC)
Yes, that is the kind of situation I have in mind. A right proper ) 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)
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.
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)

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

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)

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

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

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?
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.
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.
b
}
22:59, 19 November 2017 (UTC)
Worldcat sometimes maps invalid ISSNs to publications. – Jonesey95 (talk) 00:08, 20 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.

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:

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)

message-id error

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

|message-id= doesn't have < > characters. I'm not sure what "make sure that it contains @ between left and right identifiers" mean however, but |[email protected]@ doesn't work.

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)
@
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.
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 ([email protected] 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)

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)
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 {{
b
} 16:43, 29 November 2017 (UTC)

PubMed Identifier on Cite Journal Template

Can an admin change the link(s) to

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.
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
b
} 19:19, 29 November 2017 (UTC)