Help talk:Citation Style 1/Archive 61

Archive 55

←

Archive 59

Archive 60

Archive 61

Archive 62

Archive 63

→

Archive 65

Date format - "Midsummer 1911"

The instructions state that a journal's own date format should be followed - in this case, "Midsummer 1911". However that generates a red error. What should be done? Andy Dingley (talk) 10:48, 21 October 2019 (UTC)

I doubt any journal would have such publication date. It is very likely that this is an issue "name", in which case it can be inserted in the |issue= field. Journals with such seasonal dates usually provide an actual publication schedule near the editorial masthead or elsewhere in front matter. Look for text like "Published the first week of July", or similar, and cite the date appropriately. 69.94.58.75 (talk) 11:10, 21 October 2019 (UTC)

"I doubt that" is WP:OR and is not how we should treat external metadata. WIKINEOLOGISMs are bad enough as it is. It might even be right, but it's not how we should treat metadata which has been given to us from an external source.

The magazine here is The Shipbuilder, which AFAICS was quarterly with additional special subject-themed issues from time to time (costing several times the usual cover price, and presumably thicker), such as this. Now "Special Issue 1911" would be a reasonable description of it, but that doesn't fit with |date= either. 'June 1911' is no good because that would have been the regular quartely issue, a different magazine. Here's an archive source for it, using 'Midsummer 1911' https://www.gjenvick.com/OceanTravel/Titanic/25-ImageLibrary/TheShipbuilder-01-WhiteStarLine.html There's a cover scan which seems to describe it as "Special Issue, 1911", because there was often a desire to make these special issues less time-specific, so giving them a longer sales life. Andy Dingley (talk) 12:15, 21 October 2019 (UTC)

This is about this citation at Arrol Gantry? Do you have a copy of that periodical in hand? If not, then it would appear to me that you are citing the Gjenvick-Gjønvik Archives website so perhaps the citation should read:

{{Cite web |website=Gjenvick-Gjønvik Archives |title=Titanic Images - The Shipbuilder - 2: Harland & Wolff |at=Fig. 3: Plan of the Queen's Island Works |access-date=2019-10-21 |url= https://www.gjenvick.com/OceanTravel/Titanic/25-ImageLibrary/TheShipbuilder-02-HarlandAndWolff.html}}

"Titanic Images - The Shipbuilder - 2: Harland & Wolff". Gjenvick-Gjønvik Archives. Fig. 3: Plan of the Queen's Island Works. Retrieved 2019-10-21.

—Trappist the monk (talk) 13:22, 21 October 2019 (UTC)

That's an awful citation. It presents the archive as if they're the authors. It also hides the real source, making it hard for a future editor to find alternative routes to the real source, should the website disappear in the future. Nor does it answer the question. Andy Dingley (talk) 14:17, 21 October 2019 (UTC)

I'm confused. On that web page, the cover of the issue clearly shows the date as "1911" and the issue as "Special Number" (note: not "Special Issue", text possibly invented by the editor above; be careful out there!). I see "Midsummer" only in the text of the web page, so it might be a word that was invented for the web page. Unless I had the issue in hand and could verify I would use "year=1911" and "issue=Special Number" or just "issue=Special", because that is what is clearly verifiable from the scans. – Jonesey95 (talk) 14:31, 21 October 2019 (UTC)

Splitting onto |issue= might work. Andy Dingley (talk) 14:43, 21 October 2019 (UTC)

The way this is presented, it is not a citation of a magazine. The source here is an online archive. Absent a full citation of a consulted magazine copy, Trappist's citation is the correct way to go about it. And this has nothing to do with authors, who are correctly omitted in Trappist's rendition. 24.105.132.254 (talk) 14:48, 21 October 2019 (UTC)

(edit conflict)

You did not answer my question to you: Do you have a copy of that periodical in hand? WP:SAYWHEREYOUGOTIT always applies. If you do not have a copy of the periodical in hand, you are citing the website. It is not clear to me that the Gjenvick-Gjønvik Archives webpage is a faithful facsimile of the periodical. Sure, the images are, but is the (limited amount) of text directly quoted from the periodical or is it paraphrased by Gjenvick-Gjønvik Archives? Is that all of the text that there is in the periodical? I think not.

You can archive that page at archive.org so that if the Gjenvick-Gjønvik Archives webpage goes away you can fall-back on the archived copy with |archive-url= set to the url of that archive and |url-status=live.

Alternately, you can cite the magazine itself:

{{Cite magazine |magazine=The Shipbuilder |volume=VI |issue=Special Number |date=1911 |title=The Builders of the "Olympic" and "Titanic" |at=Fig. 3: Plan of the Queen's Island Works |url= https://archive.org/details/the_shipbuilder_special_numbers_images_201909/page/n197 |via=Internet Archive}}

"The Builders of the "Olympic" and "Titanic"". The Shipbuilder. Vol. VI, no. Special Number. 1911. Fig. 3: Plan of the Queen's Island Works – via Internet Archive.

—Trappist the monk (talk) 15:05, 21 October 2019 (UTC)

Virtually all citation styles lead off the citation with either the authors' names, or the title of the article (or larger work if not an article). If necessary, the so-called title can be a description devised by the person writing the citation and enclosed in square brackets. But in this case, we can't read the article in The Shipbuilder so we can't name the author, we can't give the exact title of the article, and we can't even give a decent description of the article. I see no choice but to cite the archive rather than the article, although the fact that The Shipbuilder is the original source should be mentioned. Jc3s5h (talk) 15:02, 21 October 2019 (UTC)

Why wouldn't publications be dated Midsummer? There are certainly academic journals that (as an affectation, I think) have other date formats like "Michaelmas". See e.g. The Michaelmas 2017 issue of Clinical Neuroscience (oddly, they also have "Michaelmas" as an issue number rather than a date, so that would probably be allowed by the templates), the Trinity/Michaelmas 2017 issue of Law and Justice. —David Eppstein (talk) 16:30, 21 October 2019 (UTC)

I know why they shouldn't: Midsummer is hemisphere dependent (which is also why periodicals shouldn't use season dates). That such dates aren't a good idea, has never stopped periodicals from using them. cs1|2 can (and does) support named dates, though, at the moment, only one: Christmas. Other named dates can be added if there is sufficient need to do so.

—Trappist the monk (talk) 16:44, 21 October 2019 (UTC)

The other reason not to use season dates is that (even assuming Northern Hemisphere) I can never tell whether Winter 2017 should come before or after Summer 2017, because the season boundaries overlap the year boundaries. But still, we should accurately represent what they actually do, not what they should do. —David Eppstein (talk) 17:46, 21 October 2019 (UTC)

This seems like an unnecessary diversion. All public materials are made so (published) at certain date(s), independent of how cute or boring (depending on your perspective) the material's publishers may be. And such material will have the actual publication date or range somewhere, in non-pseudoironic language. It can be rather hard to market or distribute said material otherwise. The actual publication date(s) (that's the objective - as in factual - information) can be found. If one wants to cite properly, one will make some sort of effort to find them. Anyway, they can always ask here if they are lazy. 24.105.132.254 (talk) 18:31, 21 October 2019 (UTC)

In case I was not clear, I am not saying that information such as these special names should not be included in the citation. On the contrary, since that info may be a way to discover the source. I just don't think that these should be |date= values. 24.105.132.254 (talk) 18:37, 21 October 2019 (UTC)

• You're confusing "they shouldn't" with "they don't". It's not WP's role to redefine how a journal chooses to identify its issues. Andy Dingley (talk) 19:01, 21 October 2019 (UTC)

Missing spacing after colons

Is there supposed to be no space rendered after the colon following the parameter denotations Bibcode and doi? If so, why exactly?--Hildeoc (talk) 14:41, 23 October 2019 (UTC)

Can't say for sure other than that is how |doi= has been rendered for a very long time:

Cite journal comparison

Wikitext	{{cite journal|doi=10.12345/12345|journal=Journal|title=Title}}
Old	"Title". Journal. doi:10.12345/12345.
Live	"Title". Journal. doi:10.12345/12345.

—Trappist the monk (talk) 15:09, 23 October 2019 (UTC)

2.6 Visual presentation and other representation of DOI names. 24.105.132.254 (talk) 15:35, 23 October 2019 (UTC)

@Trappist the monk: Thanks – also @24.105.132.254! What about Bibcode, then?--Hildeoc (talk) 15:37, 23 October 2019 (UTC)

It doesn't seem that "bibcode" is the identifier's official label. As far as I can tell "ref code" or "bibliographic reference code" is used to refer to the id, again not sure if these are official labels. As a matter of variance, Wikipedia's own {{Bibcode}} adds a hard space before the number. 24.105.132.254 (talk) 15:51, 23 October 2019 (UTC)

Language description needed for elements of cite

I'm working on articles employing Greek, containing quoted ancient or modern text, etc. Not surprisingly, the modern quotes actually have cites. Unfortunately (as likely is true for other major languages?) parts of those cites contain Greek language text, either wholly or in part. In one cite I might find "|publisher=Έκδοσις Μεγάλης Στρατιωτικής και Ναυτικής Εγκυκλοπαιδείας". In another cite might be "|author=ΒΙΚΤΩΡΑΣ ΝΕΤΑΣ". Another might have "|title=Πολυτεχνείο: Η δίκη των Συνταγματαρχών".

I see in the documentation some reference to different forms for specific cite parts, e.g.

• |title=Tōkyō tawā |script-title=ja:東京タワー |trans-title=Tokyo Tower
• |chapter=Tōkyō tawā |script-chapter=ja:東京タワー |trans-chapter=Tokyo Tower

and of course there is "language: The language in which the source is written" to describe the text within the work/edition as a whole.

Is there a general mechanism to say "here is the author's name and it is in Greek"? Or publisher? Or we have only the original title in the original Greek? If the purpose of cites is to sort and qualify the identifying qualities, shouldn't language be one of those qualities?

Note that this is separate from the usage in something like

|quote=«Αποδέχομαι την συμμετοχήν μου ...

where one is able to insert language qualification inline, like so:

|quote={{lang|el|«Αποδέχομαι την συμμετοχήν μου ...}}

The other example cite parts mentioned above get quite sick if language templates are inserted in their texts.

While someone might say that 'everyone' could recognise these as Greek, and so no qualification is needed, how are you on your Coptic? - {{lang|cop|ⲠⲚⲞⲨⲦⲈ ⲠϢⲎⲢⲈ ⲚⲞⲨⲰⲦ}} Shenme (talk) 02:44, 21 October 2019 (UTC)

This doesn't answer all of your questions, but according to MOS:ROMANIZATION we should transliterate author and publisher names into the Roman alphabet, not keep them in Greek. —David Eppstein (talk) 03:28, 21 October 2019 (UTC)

With the exception of |trans-map=, all |trans-<param>= parameters have a matching |script-<param>=. These are the parameters for which language has been deemed important.

base param	trans-param	script-param
article	trans-article	script-article
chapter	trans-chapter	script-chapter
contribution	trans-contribution	script-contribution
entry	trans-entry	script-entry
journal	trans-journal	script-journal
magazine	trans-magazine	script-magazine
map	(sandboxed)	trans-map
newspaper	trans-newspaper	script-newspaper
periodical	trans-periodical	script-periodical
section	trans-section	script-section
title	trans-title	script-title
website	trans-website	script-website
work	trans-work	script-work

|language= accepts a comma-separated list of languages; not just one language as you state in your post. There is nothing in cs1|2 to say that author / editor / ... names are written in a particular script. Romanizing names per MOS:ROMANIZATION might be the appropriate thing to do until the name-list parameters are (if they ever are) modified to support a |trans-<param>= form.

Do not use {{lang}} in any of the parameters that contribute to the citation's metadata. The parameters are listed on all cs1|2 template doc pages; see for example: Template:Cite book#COinS metadata is created for these parameters.

I will look into what is needed to support |script-map=.

—Trappist the monk (talk) 14:02, 21 October 2019 (UTC)

I have added |script-map= to the sandbox:

{{Cite map/new |map=Map |trans-map=Trans Map |script-map=zh:Script Map |title=Title}}

"Map" Script Map [Trans Map] (Map). Title.

—Trappist the monk (talk) 16:25, 21 October 2019 (UTC)

until the name-list parameters are (if they ever are) modified to support a |trans-<param>= form I'm sure you meant to say |script-<param>= form, as translating names (trans- prefix) doesn't make sense. (Unfortunately, "trans" can be interpreted as both "translation" and "transcription", which leads to confusion; it would be better to use transl- .) — UnladenSwallow (talk) 15:01, 26 October 2019 (UTC)

i18n of limited parameter values

There are several cs1|2 parameters that accept only certain parameter values: |url-status= will only accept dead, live, usurped, unfit, bot: unknown is one example of these kinds of parameters.

A discussion at my talk page showed that the current module suite doesn't provide good support for internationalization of these parameter values. So, I have tweaked the sandboxen to do that.

Here is an example of that change that uses French and German keywords (these keywords will be removed from the ~/Configuration/sandbox before updating the live modules):

{{cite journal/new |journal=Journal |mode=cs2 |last=Brown |first1=Alpha Bravo |last2=Red |first2=Charlie Delta |name-list-style=vanc |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2019-10-08 |url-status=vivre |doi=10.1234/12345 |doi-access=frei}}

Brown AB, Red CD, "Title", Journal, doi:10.1234/12345, archived from the original on 2019-10-08 {{cite journal}}: Invalid |doi-access=frei (help); Invalid |url-status=vivre (help)

And, unsupported keywords are still flagged as errors:

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

Title. {{cite book}}: Invalid |url-access=frei (help)

—Trappist the monk (talk) 14:04, 27 October 2019 (UTC)

Possible page numbering regression

See also: Help_talk:Citation_Style_1/Archive_60 § Template:Hyphen_is_corrupted

The documentation for pages= says:

Hyphens are automatically converted to en dashes; if hyphens are appropriate, for example: pp. 3-1–3-15, use |pages=3{{hyphen}}1{{ndash}}3{{hyphen}}15

Presumably, that advice used to work, but it no longer appears to (the example below uses |pages=3{{hyphen}}1{{ndash}}3{{hyphen}}15):

Cite journal comparison

Wikitext	{{cite journal|journal=Journal|pages=3-1–3-15|title=Title}}
Live	"Title". Journal: 3-1–3-15.
Sandbox	"Title". Journal: 3-1 – 3-15.

Did I miss a change that necessitates updating this documentation? Is this related to this recent discussion about large page numbers? – Jonesey95 (talk) 05:11, 26 October 2019 (UTC)

That occurs due to function hyphen_to_dash in Module:Citation/CS1 which includes mw.text.split (str, '%s*[,;]%s*'). That regards any commas or semicolons as page number separators. The fact that the semicolon is removed from the - produced by {{hyphen}} gives the strange result. It seems that was introduced on 29 September 2018 and surrounding the page numbers with double parentheses works. Johnuniq (talk) 06:36, 26 October 2019 (UTC)

Who do we approach to get this fixed? - Chris.sherlock (talk) 20:03, 26 October 2019 (UTC)

Trappist the monk (talk · contribs) is just about the only person that can do maintenance on this template. Technically anyone with LUA skills could though, but that's pretty rare on Wikipedia. Headbomb {t · c · p · b} 21:58, 26 October 2019 (UTC)

"Technically anyone with LUA skills could" isn't true. I would consider myself to have Lua skills, but consider the coding of citation modules to be too complex for me to understand and make fixes to. * Pppery * _{it has begun...} 22:28, 26 October 2019 (UTC)

Hence the 'technically', rather than 'in practice' Headbomb {t · c · p · b} 22:30, 26 October 2019 (UTC)

And it appears that if Trappist doesn't want to do something it won't get done. ♦ J. Johnson (JJ) (talk) 21:31, 27 October 2019 (UTC)

I gave a diff at the parallel discussion on WP:VPT with the solution that I hinted at above, namely: I fixed Antimatter with double-parens in this edit. The idea is that the double parentheses tell the module that you are sure the page numbering syntax does not need auto-fixing. The module does not need to be changed. Johnuniq (talk) 22:11, 26 October 2019 (UTC)

Then I guess the documentation needs to be modified. I have done so. Here's the above citation with double parentheses:

Cite journal comparison

Wikitext	{{cite journal|journal=Journal|pages=((3-1–3-15))|title=Title}}
Live	"Title". Journal: 3-1–3-15.
Sandbox	"Title". Journal: 3-1–3-15.

Thanks for the help! – Jonesey95 (talk) 23:51, 26 October 2019 (UTC)

The documentation is fine, what needs to be updated is the POLA-violating behaviour of the template.

• {{cite book |article=Picking a band |title=The ARRL Operating Manual |edition=8th |editor=Ford, Steve |page=1{{hyphen}}15 |publisher=[[American Radio Relay League]] |place=Newington, CT}}
• Ford, Steve (ed.). "Picking a band". The ARRL Operating Manual (8th ed.). Newington, CT: American Radio Relay League. p. 1-15.

works just fine. So should the problematic example above. Headbomb {t · c · p · b} 21:58, 27 October 2019 (UTC)

Support citewatch=... or something like it

WP:CITEWATCH is a compilation of potentially unreliable citations (see Signpost for background). It's not perfect, and it doesn't catch everything, but it does cover a lot, and will likely cover more as things get developped. However, one thing it doesn't do is have a way of determining if a citation has already been checked to see if it was appropriate to cite it. Supporting a |citewatch=yes or similar (|cw-check=ok maybe?) would let us build the compilations without having to verify the same citations over and over. For example, if citation to Pharmacologia (a source that's on Beall's list was an appropriate citation) and other questionable sources we deemed acceptable, they could be marked as such with

• {{cite journal |doi=10.5567/pharmacologia.2012.344.347 |title=Pharmacological Properties of Scoparia Dulcis: A Review |year=2012 |last1=Murti |first1=Krishna |last2=Panchal |first2=Mayank |last3=Taya |first3=Poonam |last4=Singh |first4=Raghuveer |journal=Pharmacologia |volume=3 |issue=8 |pages=344 |cw-check=ok}}

And, upon the next bot run a table like this

Rank	Target/Group	Entries (Citations, Articles)	Total Citations	Distinct Articles	⁠Citations/article⁠
106	Journal of Physical Therapy Science [Beall's journal list]	Journal of Physical Therapy Science (15 in 11)	15	11	1.364
601	Pharmacologia [Beall's journal list]	Pharmacologia (1 in 1)	1	1	1.000

could be updated to something like

Rank	Target/Group	Entries (Citations, Articles)	Total Citations	Distinct Articles	⁠Citations/article⁠
106	Journal of Physical Therapy Science [Beall's journal list]	Journal of Physical Therapy Science (7 ? and 8 ✓ in 11)	15	11	1.364
601	Pharmacologia [Beall's journal list]	Pharmacologia (1 ✓ in 1)	1	1	1.000

For now |cw-check= would just be a whitelisted parameter that does nothing, although there could be some validation on what's acceptable (e.g. |cw-check=yes, |cw-check=ok) with a maintenance category for anything else. Headbomb {t · c · p · b} 03:21, 14 June 2019 (UTC)

This is a terrible idea - it isn't the purpose of relatively obscure wikiprojects to declare themselves the arbiter of what is a reliable source and what isn't (or to promote themselves using what is effectively the standaed reference system on Wikipedia - we shouldn't be giving references a badge of shame based on a very localised and dubious idea of what is reliable and what isn't - suspect sources should be discussed at Wikipedia:Reliable sources - if deemed unreliable for the context it should be removed, and if reliable for the use, it should be kept.Nigel Ish (talk) 20:45, 20 July 2019 (UTC)

@Nigel Ish: It's not a thing that would be in any way visible to the reader. It would simply be to have |cw-check=yes not throw an error like it currently does (e.g. Smith, J. (2006). "Foobar". Quack Journal of Nonsense. 23 (3): 24. doi:10.1234/123456789. {{cite journal}}: Unknown parameter |cw-check= ignored (help)). Likewise, WP:CITEWATCH does not take a position on weather or not a source is appropriate to cite, it just raises a flag that it's probably a good idea to double check. Headbomb {t · c · p · b} 20:55, 20 July 2019 (UTC)

My suggestion would be to have a param to signify whether the citation is being used as a primary source. That way, editors reviewing known unreliable sources can quickly parse how the citation is being used. Such a use case wouldn't be limited to citewatch. czar 20:50, 20 July 2019 (UTC)

I agree with Czar that it's better to focus on the specific content and how it's used. For instance, most people will look at whether the authors are authoritative, whether the paper builds on academic literature, any sign of substantive peer review having been performed, signs of (un)sound methodology. Some call it being "refereeable" https://arxiv.org/help/moderation or "scholarly". For us it would be "citable", to account for things like primary references, but that might prove confusing. Nemo 07:21, 25 July 2019 (UTC)

Well that's what WP:CITEWATCH picks up. Citations with high likelihood of being unreliable. Having support for |cw-check= (or something similar), would let us have (click [show] to see)

Rank	Target/Group	Entries (Citations, Articles)	Total Citations	Distinct Articles	⁠Citations/article⁠
47	Science Publishing Group [Beall's publisher list · Beall's publisher list / update] Social Sciences could be multiple other journals. Several of SPG journals are named either identically or are very similar to other publications, e.g. International Journal of Data Science and Analysis vs International Journal of Data Science and Analytics and may thus have similar ISO 4 abbreviations.	Hydrology (disambiguation) Hydrology (3 ? in 1, 2, 3) Science Publishing Group American Journal of Applied Mathematics (1 ✓ in 1) Bioprocess Engineering (1 ? in 1) Communications (15 ? in 14) Education Journal (2 ? in 1, 2) Industrial Engineering (2 ? in 1, 2) Social Sciences (disambiguation) Social Sciences (19 ? in 19)	43	42	1.024

Or similar (ignore the "All 0", it's a counting error due to how the template does its counting based on the currently logic) Headbomb {t · c · p · b} 09:54, 25 July 2019 (UTC)

To be clear, I do agree on the usefulness of facilitating such an outcome. Nemo 13:57, 30 July 2019 (UTC)

I would not support this. The global approach it is designed to facilitate is contrary to the idea in WP:RS that context matters. The reliability of sources used in an article is a matter to be discussed with reference to that article on the talk page or WP:RSN. It is not the function of citation templates to be applying scarlet letters to sources in article space. Kanguole 14:43, 30 July 2019 (UTC)

Again, you misunderstand the purpose. Absolutely nothing would be displayed in articles. There would be no Scarlett letters. Headbomb {t · c · p · b} 14:46, 30 July 2019 (UTC)

It is designed to facilitate a global approach to reliability, and it would put markers in wikitext, right? Kanguole 14:50, 30 July 2019 (UTC)

"A global approach to reliability" I don't know what that even means. See the Signpost article for what the citewatch is: a tool that identifies potentially problematic citations. |cw-check=ok would let us flag false positives, so that people who use the citewatch don't waste time reviewing the same potentially problematic sources over and over. The alternative is something ugly and error-prone like |journal=MIT Review<!--Citewatch: This is not the hijacked journal, and is OK--> Headbomb {t · c · p · b} 14:58, 30 July 2019 (UTC)

I think a parameter used in the individual citations is the opposite of a one-size-fits-all solution: it stresses that judgements need to be made on the individual article. However, I agree it's easy to misunderstand, so we'd need a very clear name for it. Nemo 16:05, 30 July 2019 (UTC)

Valid DOI ending in punctuation

Category:CS1 errors: DOI is showing error for doi:10.1130/focus122009.1. because it ends in punctuation (see Paleocene), but it's a valid DOI.  — Chris Capoccia 💬 02:08, 26 October 2019 (UTC)

This is strange. We have not allowed spaces in DOIs or full stops (periods) at the end of a DOI for about five years, but looking at the current version and archived versions of the DOI numbering spec, I do not see a mention of these restrictions. I did a little digging in the archives of this page, and I found the thread where these errors were discussed, but I don't see a rationale for them based on a specification. That said, almost every time a space, terminal period, or en dash exists in a DOI, it is invalid. Maybe we just need to depend on Citation bot to mark DOIs as broken, like this. Thoughts are welcome. – Jonesey95 (talk) 04:56, 26 October 2019 (UTC)

Is this doi really broken? As far as I know, this is the first notice here of a doi that ends with a punctuation character. Are there other dois that end with punctuation characters?

I have reported the dot-less doi to cross ref and invited them to participate in this discussion.

—Trappist the monk (talk) 11:55, 26 October 2019 (UTC)

This DOI is functional, in the sense that it resolves correctly. Removing the period results in no link to a web page. – Jonesey95 (talk) 15:05, 26 October 2019 (UTC)

Our article digital object identifier says only that "most legal unicode" characters are allowed in doi strings, and that they are case-insensitive. It says nothing about syntactical restrictions. This appears to be yet another case where something that citations often don't do has been interpreted rigidly by the templates as a hard prohibition. This rigidity makes the templates unnecessarily difficult to use. —David Eppstein (talk) 20:36, 29 October 2019 (UTC)

Apparently we haven't discussed this terminal punctuation thing much. I didn't find any discussion that indicates the why of the terminal punctuation prohibition.

Help talk:Citation Style 1/Archive 4 § doi subthread – original implementation

Help talk:Citation Style 1/Archive 8 § DOI throwing an error – wherein is discussed erroneous inclusion of terminal punctuation

I suspect that the extraneous punctuation tacked on to the end of a valid doi is the reason that we have that error detection in the code. After all, en.wiki editors do add extraneous punctuation to cs1|2 parameter values which is why we now have Category:CS1 maint: extra punctuation‎ (4) (currently constrained to ,:; characters).

We might implement the doubled parentheses markup mechanism to suppress the error message (cs1|2 does not modify the identifier) so, for those obviously rare cases where a trailing dot or trailing comma really is part of the doi identifier, editors might write:

{{cite journal |last1=Belcher |first1=C. M. |title=Reigniting the Cretaceous-Palaeogene firestorm debate |journal=Geology |year= 2009 |volume=37 |issue=12 |pages=1147–1148 |doi=((10.1130/focus122009.1.)) |bibcode=2009Geo....37.1147B}}

—Trappist the monk (talk) 13:08, 30 October 2019 (UTC)

Citing music videos with Template:Cite AV media

Per MOS:NOITALIC, short musical works, such as songs (and therefore also music video titles; the MOS specifically lists songs, album tracks and other short musical works) should appear between quotation marks but not be italicized. Template:Cite music video redirects to Template:Cite AV media, yet the latter automatically italicizes the title of the work. Is there any way to circumvent this other than by entering the work title as below?

|title = ''"Music video title that should not be italicized"''

Furthermore, should there be a separate template to handle cases like this? Armadillopteryx^talk 02:13, 28 October 2019 (UTC)

In citations it is good practice to distinguish the source. The work is italicized for emphasis. Citation style doesn't have the same objectives that body style has. Normally, short works were not widely published (in a conventional sense) as standalone publications. Usually it was easier to find them (and therefore cite them) in collections. That citation would "quote" the title of the short included in the larger collection. I do not think another template is necessary. 100.38.149.132 (talk) 11:11, 28 October 2019 (UTC)

{{cite av media}} has italicized title from its pre-{{citation/core}} days; see this 2006 edit when the template was still {{cite video}}.

In cs1|2, quoted upright font is reserved for those things that are sub-things of a larger thing being cited; chapters of a book; articles of a journal/magazine/newspaper; entries of an encyclopedia; pages of a website. Unless the quote marks (") are actually part of the work's title, they should not be included in |title= because they will also be included in the citation's metadata where they will be wrong.

This template suffers from a far greater problem in my mind and that is the use of |people= as a parameter and with en.wiki editors' inclusion of other 'stuff' in that parameter (producer, director, assistant whatever; affiliations, ...). Because |people= is an alias of |authors=, none of the contributors are included in the citation's metadata. A solution to this might be to enable |contributorn= for this template and also create a |rolen= parameter so that en.wiki editors might write:

{{cite av media |contributor1=Contributor Name |role1=Contributor's role |title=Media Title}}

and which might render as:

Contributor Name (Contributor's role). Media Title

—Trappist the monk (talk) 14:02, 30 October 2019 (UTC)

My memory on the issue is foggy, but I believe the reason the unfortunate "people" was chosen, was because in some creative works like theater plays, films etc. there is no unambiguous "author". Several people may have important roles in creating the work, and the norm in such works is to credit them. I vote for the contributor-role combination. 108.182.15.109 (talk) 15:13, 30 October 2019 (UTC)

Template:Cite_podcast should support |number=

Podcast episodes are usually numbered, but {{cite podcast}} doesn't support a parameter for them. It should. --AntiCompositeNumber (talk) 01:31, 30 October 2019 (UTC)

You do not give an example where |number= might be required. There was a previous discussion that might be useful:

Help talk:Citation Style 1/Archive 36 § Citing podcast episodes by number

—Trappist the monk (talk) 14:10, 30 October 2019 (UTC)

These are the examples of podcasts that I could quickly find that have numbers but don't put them in the titles: [1] [2] [3] [4]. In other podcasts, the combined number and title string differs across platforms, often changing the prefix or punctuation around the number. Furthermore, I wouldn't write |title=#80 | Virtual Choir for the same reason I wouldn't write |title=Important Book, 100th Edition. To the point about metadata in the previous discussion, just because your particular client does not expose the metadata does not mean it doesn't exist. --AntiCompositeNumber (talk) 14:39, 30 October 2019 (UTC)

Please do not put words into my mouth that I did not speak. In the previous discussion, I said nothing about metadata.

I've tweaked the module sandbox:

{{cite podcast/new |host=Dallas Taylor |subject2=Eric Whitacre |title=Virtual Choir |work=Twenty Thousand Hertz |number=80 |url=https://www.20k.org/episodes/virtualchoir}}

Dallas Taylor; Eric Whitacre. "Virtual Choir". Twenty Thousand Hertz (Podcast). No. 80.

—Trappist the monk (talk) 17:13, 30 October 2019 (UTC)

i18n: language-category tweaks

A discussion on my talk page has prompted changes to the cs1|2 language support. I have tweaked Module:Citation/CS1/sandbox so that it emits a category when |language= is set to the local language and when a flag in Module:Citation/CS1/Configuration/sandbox, local_lang_cat_enable is set to true. At en.wiki we do not categorize articles with cs1|2 templates that have |language=en or |language=English so here local_lang_cat_enable is set to false.

As part of this change, I have also fixed the |script-<param>= code so that language-names used in the titles of subcategories in Category:CS1 uses foreign language script are in the local language instead of in English.

—Trappist the monk (talk) 14:49, 2 November 2019 (UTC)

access-date for archived urls

I fixed a dead link by adding a link to its entry in the Wayback Machine. There was already an access-date parameter, do I now update it? The documentation is not clear on this; maybe an additional archive-access-date parameter is needed. – gpvos (talk) 17:11, 3 November 2019 (UTC)

The edit: [5]. – gpvos (talk) 17:12, 3 November 2019 (UTC)

No. |access-date= identifies the date when the source linked by |url= supported the en.wiki article text. Adding an archive link does not change that. In your example, I would suggest choosing an archive snapshot closer to the 20 August 2013 access date than the 2018 snapshot that you chose; this 2013-08-15 snapshot perhaps. Besides that, no further action on your part is required.

—Trappist the monk (talk) 17:36, 3 November 2019 (UTC)

URL from archive.org is marked as bad URL

Does anyone else get this error message? I've noticed it in the citation named "Guardian: how the rich" in Panama Papers, and I suspect that it's because the archive.org URL contains a second "http://" inside it, because of the truncated way the URL is displayed, but that doesn't ever appear to have been recognised as a problem before. I suspect a bug. --Florian Blaschke (talk) 09:54, 8 November 2019 (UTC)

@Cobaltcigs: Thanks a lot; I had kept looking at the wrong ref, because the one with the problem was "OCCRP Giant leak", and it turned out a mere typo.  Fixed --Florian Blaschke (talk) 14:21, 8 November 2019 (UTC)

revised language support

I have tweaked Module:Citation/CS1/sandbox and Module:Citation/CS1/Configuration/sandbox to harmonize cs1|2 with Module:lang because the various {{xx icon}} templates are deprecated. These {{xx icon}} templates are not related at all to cs1|2 except in how cs1|2 displays language names from IANA and ISO 639-2 and -3 codes. More detail is available in these four discussions (which are mostly me talking and no one responding):

• Talk:Blackfoot language § language naming inconsistencies
• Talk:Ilocano language § language naming inconsistencies
• Talk:Ripuarian language § language naming inconsistencies
• Talk:Taiwanese Hokkien § language naming inconsistencies

Here is how the changes look:

• Blackfoot:

Cite book comparison

Wikitext	{{cite book|language=blackfoot|title=Title}}
Live	Title (in Blackfoot).
Sandbox	Title (in Blackfoot).

Cite book comparison

Wikitext	{{cite book|language=bla|title=Title}}
Live	Title (in Blackfoot).
Sandbox	Title (in Blackfoot).

• Ilocano:

Cite book comparison

Wikitext	{{cite book|language=Ilocano|title=Title}}
Live	Title (in Ilocano).
Sandbox	Title (in Ilocano).

Cite book comparison

Wikitext	{{cite book|language=ilo|title=Title}}
Live	Title (in Ilocano).
Sandbox	Title (in Ilocano).

• Kölsch:

Cite book comparison

Wikitext	{{cite book|language=kölsch|title=Title}}
Live	Title (in Kölsch).
Sandbox	Title (in Kölsch).

Cite book comparison

Wikitext	{{cite book|language=kolsch|title=Title}}
Live	Title (in Kölsch).
Sandbox	Title (in Kölsch).

Cite book comparison

Wikitext	{{cite book|language=ksh|title=Title}}
Live	Title (in Kölsch).
Sandbox	Title (in Kölsch).

• Colognian:

Cite book comparison

Wikitext	{{cite book|language=Colognian|title=Title}}
Live	Title (in Colognian).
Sandbox	Title (in Colognian).

Cite book comparison

Wikitext	{{cite book|language=ksh-x-colog|title=Title}}
Live	Title (in Colognian).
Sandbox	Title (in Colognian).

• Ripuarian:

Cite book comparison

Wikitext	{{cite book|language=Ripuarian|title=Title}}
Live	Title (in Ripuarian).
Sandbox	Title (in Ripuarian).

Cite book comparison

Wikitext	{{cite book|language=mis-x-ripuar|title=Title}}
Live	Title (in Ripuarian).
Sandbox	Title (in Ripuarian).

• Taiwanese Hokkien:

Cite book comparison

Wikitext	{{cite book|language=Taiwanese Hokkien|title=Title}}
Live	Title (in Taiwanese Hokkien).
Sandbox	Title (in Taiwanese Hokkien).

Cite book comparison

Wikitext	{{cite book|language=nan-tw|title=Title}}
Live	Title (in Taiwanese Hokkien).
Sandbox	Title (in Taiwanese Hokkien).

• Min Nan Chinese:

Cite book comparison

Wikitext	{{cite book|language=Min Nan Chinese|title=Title}}
Live	Title (in Min Nan Chinese).{{cite book}}: CS1 maint: unrecognized language (link)
Sandbox	Title (in Min Nan Chinese).{{cite book}}: CS1 maint: unrecognized language (link)

Cite book comparison

Wikitext	{{cite book|language=nan|title=Title}}
Live	Title (in Minnan).
Sandbox	Title (in Minnan).

—Trappist the monk (talk) 19:07, 3 November 2019 (UTC)

I think Trappist said it best at the Taiwainese discussion (copy-pasted to the other talk pages as well): Article name should match category names should match template renderings. I support consistency. When discussions lead to changes in article titles, it is straightforward to change the article, affected categories, and templates to match the new article titles. – Jonesey95 (talk) 22:35, 3 November 2019 (UTC)

mis-x-colog changed to ksh-x-colog per discussion at Talk:Ripuarian language § language naming inconsistencies.

—Trappist the monk (talk) 14:45, 13 November 2019 (UTC)

|script-title= and cite encyclopedia

There is a bug in the error reporting for |script-title= when it is used in {{cite encyclopedia}}. Fixed in the sandbox I think:

Cite encyclopedia comparison

Wikitext	{{cite encyclopedia|encyclopedia=New Encyclopedia of Philosophy|first=V.K.|language=ru|last=Shohin|publisher=Institute of Philosophy of the Russian Academy of Sciences, National public and Science Foundation|script-title=ПАПА–ПУНЬЯ|trans-title=pāpa–puñña|url=http://iphras.ru/elib/2256.html#|year=2010}}
Live	Shohin, V.K. (2010). ПАПА–ПУНЬЯ [pāpa–puñña]. New Encyclopedia of Philosophy (in Russian). Institute of Philosophy of the Russian Academy of Sciences, National public and Science Foundation. {{cite encyclopedia}}: Invalid |script-title=: missing prefix (help)
Sandbox	Shohin, V.K. (2010). ПАПА–ПУНЬЯ [pāpa–puñña]. New Encyclopedia of Philosophy (in Russian). Institute of Philosophy of the Russian Academy of Sciences, National public and Science Foundation. {{cite encyclopedia}}: Invalid |script-title=: missing prefix (help)

—Trappist the monk (talk) 16:20, 14 November 2019 (UTC)

expanding |script-title= language codes

I have been picking my way through Category:CS1 errors: script parameters. There have been several instances of |script-title= where the language of the source is Ottoman Turkish. That language has an ISO 639-3 code of ota. cs1|2 does not support three-character script-lang codes (ISO 639-2, -3) so I have fixed that in the sandbox.

Cite book comparison

Wikitext	{{cite book|edition=5th|language=Ottoman Turkish|location=Hicaz|page=117|publisher=Vilayet Matbaası [Vilayet Printing House]|ref=Vilayet Yearbook|script-title=ota:حجاز ولايتى سالنامه‌سى|title=Hicaz vilayeti salnamesi|trans-title=Hejaz Vilayet Yearbook|url=https://hdl.handle.net/2027/mdp.39015049569422?urlappend=%3Bseq=151|year=1892}}
Live	Hicaz vilayeti salnamesi حجاز ولايتى سالنامه‌سى [Hejaz Vilayet Yearbook] (in Ottoman Turkish) (5th ed.). Hicaz: Vilayet Matbaası [Vilayet Printing House]. 1892. p. 117.
Sandbox	Hicaz vilayeti salnamesi حجاز ولايتى سالنامه‌سى [Hejaz Vilayet Yearbook] (in Ottoman Turkish) (5th ed.). Hicaz: Vilayet Matbaası [Vilayet Printing House]. 1892. p. 117.

At the moment, ota is the only three-character code recognized for the script-lang parameters.

—Trappist the monk (talk) 14:50, 15 November 2019 (UTC)

cite database (?)

I'd really love to create a simple cite template that basically wraps around {{cite web}} but with type=database. It'd kinda be like {{cite report}} in a way? The only feature I imagine being different, though, is that |number= would probably be an alias for |id= in the same way as {{cite techreport}} has it. I tried to figure out how the code would work here, but it didn't work as I intended. –MJL ‐Talk‐^☖ 00:06, 17 November 2019 (UTC)

No templates in section headers; breaks links from watchlists.

If you want {{cite database}} to look like {{cite report}} but with |number= aliased to |id= then perhaps the best solution is to use Module:Template wrapper to wrap {{cite report}} in {{cite database}} so something like this:

{{#invoke:template wrapper|{{#if:{{{_debug|}}}|list|wrap}}|_template=cite report
 |_exclude=id, ID, number, _debug
|id={{{number|}}}
|type=none
}}

caveat lector: this is not tested.

|_exclude=id, ID, number, _debug prevents these incoming parameters from being passed directly to {{cite report}}

|id={{{number|}}} aliases |number= to |id=

|type=none prevents {{cite report}} from emitting its '(Report)' annotation

—Trappist the monk (talk) 00:30, 17 November 2019 (UTC)

I have a conceptual problem with this, unless what is specifically cited is a database report. Such reports are basically the formatted output of queries, and may be delivered through a variety of different mechanisms and front ends. It would be helpful if the OP expanded a bit on the rationale and intent of such a template. 24.105.132.254 (talk) 20:44, 17 November 2019 (UTC)

Citing online databases

How do we cite an online database that takes a string query as an input? I'm currently doing it this way:

{{cite web |url=https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=Borisov |title=JPL Small-Body Database Browser — Search string: Borisov |website=JPL Solar System Dynamics}}

"JPL Small-Body Database Browser — Search string: Borisov". JPL Solar System Dynamics.

Another option would be:

{{cite web |url=https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=Borisov |title=JPL Small-Body Database Browser |at=Search string: Borisov |website=JPL Solar System Dynamics}}

"JPL Small-Body Database Browser". JPL Solar System Dynamics. Search string: Borisov.

I don't like either. The first one puts the query string inside the quotes, which is wrong—it's not a part of the title (at least on the website shown in the example). The second one separates the title from the query, which is ugly. There's also |entry=, but it's not available in {{cite web}}. So how do I do it?

Perhaps, we should add a special parameter to {{cite web}} to handle such citations (which are quite common is scientific articles), like so:

{{cite web |url=https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=Borisov |title=JPL Small-Body Database Browser |query=Borisov |website=JPL Solar System Dynamics}}

"JPL Small-Body Database Browser", query: Borisov. JPL Solar System Dynamics.

— UnladenSwallow (talk) 20:34, 6 October 2019 (UTC)

It is generally not advisable to cite search results, as a host of things may get out of sync/change. I would cite a specific entry, and perhaps note it is part of a series in a {{link note}}. 98.0.246.242 (talk) 22:27, 6 October 2019 (UTC)

Well, we have the same situation even with ordinary web pages: a host of things may get out of sync/change. That's why we use archive-urls, which we can use just as well with search results. This particular citation is required to back up the claim of a certain specific number of comets having been discovered (see Gennadiy Borisov), so I can't cite a specific entry. Even if cited each individual entry, that would only "prove" that at least that number of comets have been discovered—it wouldn't prove that exactly that number comets have been discovered. — UnladenSwallow (talk) 23:19, 6 October 2019 (UTC)

Cite web emits metadata consistent with the item cited being a periodical. A database is not a periodical. Therefore we shouldn't use cite web at all for a database. I don't know of any cite xxx template intended for databases. I suggest not using a template at all. Jc3s5h (talk) 23:41, 6 October 2019 (UTC)

I looked at Chicago Manual of Style 17th ed., "Scientific Databases", p. 14.257. It gives this example of a footnote and bibliography entry that are similar to what you seek:

1. NASA/IPAC Extragalactic Database (object name IRAS F00400+4059; accessed April 6, 2016), http://ned.ipac.caltech.edu/.

[following bibliography entry has hanging indent in original]

NASA/IPAC Extragalactic Database (object name IRAS F00400+4059; accessed April 6, 2016), http://ned.ipac.caltech.edu/.

Jc3s5h (talk) 00:04, 7 October 2019 (UTC)

1. Cite web emits metadata consistent with the item cited being a periodical. A database is not a periodical. Therefore we shouldn't use cite web at all for a database. The Template:Cite web documentation says something entirely different: This Citation Style 1 template is used to create citations for web sources that are not characterized by another CS1 template. From which it follows that {{cite web}} is suitable for citing a database. Either your reasoning is wrong, or the documentation is wrong. 2. Thanks for the relevant CMOS excerpt. — UnladenSwallow (talk) 01:23, 7 October 2019 (UTC)

The documentation is not wrong. To suggest that {{cite web}} should only be used to cite periodicals is an entirely novel interpretation that has nothing to do with how the template's usage was understood to apply, since its inception. 98.0.246.242 (talk) 01:30, 7 October 2019 (UTC)

Then the documentation and the code are inconsistent with each other. To avoid error messages (currently hidden) one must specify a website title, and another title. The former is treated by the code like a journal title, and the latter is treated like an article title. The titles are marked in the metadata as journal and article titles respectively. Jc3s5h (talk) 01:54, 7 October 2019 (UTC)

If that's what the code does, then it's clearly wrong. I've seen {{cite web}} used for all kinds of sites that were not journals. In fact, I've never seen it used for a journal. — UnladenSwallow (talk) 02:13, 7 October 2019 (UTC)

Editors use {{cite web}} as a catch-all for everything. Editor Jc3s5h is incorrect: To avoid error messages (currently hidden) one must specify a website title... The website-required-check has been wholly disabled per this discussion at WP:AN.

—Trappist the monk (talk) 13:19, 7 October 2019 (UTC)

The sync problem with search queries in citations is not about the results, primarily. Queries do not provide consistent targets, and the query syntax itself may change. Apart from that they are susceptible to bias: they can be structured with a bias towards a desired set of results. The cited material must have an unambiguous, singular verification target. As mentioned previously, if you want to cite a set of entries in a database, cite the first one, and optionally add a note that this is one of several such entries. I would also take a look at {{cite techreport}}. 98.0.246.242 (talk) 00:31, 7 October 2019 (UTC)

Queries do not provide consistent targets… In general case, yes. In this particular case, even if Gennady Borisov discovers another 10 comets, and the Small-Body Database changes its output, the citation will still be correct, because the relevant sentence in the article says "Between 2013 and 2017, he has discovered seven comets" and the database output will always list 7 comets discovered between 2013 and 2017. The Small-Body Database is not like Google Search: it doesn't change its output rapidly, it's not user- or location-sensitive, it shows all matching results, and its output changes are incremental, i.e. new results are appended to the bottom of the output list. Apart from that they are susceptible to bias: they can be structured with a bias towards a desired set of results. The same can be said about citations in general: they can be selected with a bias towards desired conclusions. That doesn't mean that citations should not be used. Similarly, the fact that someone may use a biased query does not mean that queries should not be used. In fact, queries are better in this regard, because a query can always be inspected and is executed automatically by a machine, so a biased query would be immediately visible, while the process of citation selection by an editor is completely opaque and cannot be inspected by other editors. I would also take a look at {{cite techreport}}. I don't quite understand how to apply {{cite techreport}} in this case and would be grateful if you could expand on this. — UnladenSwallow (talk) 02:09, 7 October 2019 (UTC)

An article's positional bias is irrelevant to citations. A verifiable citation from a reliable source that supports a biased claim in an article is a good citation. However searches introduce potential confirmation bias in the structure of the citation itself. Remove this potential source of bias by not citing searches, which consist of more-or-less arbitrarily formatted questions. But apart from that, the item that supports the claim in an article must be unambiguous and consistent. We have no way of knowing if a certain query will consistently produce the same result. You may believe that a particular query is stable and well-formatted, but in the meantime you introduce an additional verification condition: I now have to verify whether the query itself is appropriately formatted, even before I arrive at the claimed proof. And all of this can, and should, be avoided. In the meantime, you are free to use any search template in support of your claim in a footnote, not a citation, as long as you expressly declare the search. 72.43.99.138 (talk) 14:14, 7 October 2019 (UTC)

To add, it seems to me that citing every record cannot be avoided if the information about the number of comets etc. is included. 98.0.246.242 (talk) 00:38, 7 October 2019 (UTC)

The way it works now is that https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=Borisov shows 7 comets discovered between 2013 and 2017 (entries starting with "C", the numbers after "C" are years of discovery) and all of them have "Borisov" in parentheses, which means that Borisov is the discoverer (the standard scheme of designating comets). Therefore, this output is enough to back up the claim that Borisov is the discoverer of exactly 7 comets (not less, not more) between 2013 and 2017. JPL's Small-Body Database is an authoritative source in astronomy. — UnladenSwallow (talk) 02:25, 7 October 2019 (UTC)

I don't dispute the reliability of the source, and I wish I could think of some way to present this better. There have been discussions about grouping citations from the same source in the past, but I don't think they went anywhere. The only other option that comes close would be a complicated application of {{harvc}}. It may be better to write your own, non-templated citation. 72.43.99.138 (talk) 15:11, 7 October 2019 (UTC)

Isn't there any other reliable source that aggregates the information? 98.0.246.242 (talk) 00:40, 7 October 2019 (UTC)

There's Minor Planet Center (https://minorplanetcenter.net), through which all the information about minor planets and comets flows, but it doesn't maintain explicit lists of who discovered what. There's a List Of Observatory Codes, but you can't click on an observatory to see all objects discovered there. So the astronomers use JPL's Small-Body Database Browser for this (among other reasons). It's used quite extensively on Wikipedia, hence my interest in finding/devising a proper way to format its citations. — UnladenSwallow (talk) 02:40, 7 October 2019 (UTC)

UnladenSwallow, we have a lot of specialized reference templates that cite databases. See {{Ethnologue22}} and {{SIMBAD link}}. Follow what they do. In the template code. They set up the url to include the search parameters. So you can write:

• {{cite web |title=Borosov |url=https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=Borisov |work=JPL Solar System Dynamics |publisher=Jet Propulsion Laboratory |accessdate=6 October 2019}}
  • "Borosov". JPL Solar System Dynamics. Jet Propulsion Laboratory. Retrieved 6 October 2019.
• {{cite web |title=11016 Borisov (1982 SG12) |url=https://ssd.jpl.nasa.gov/sbdb.cgi?ID=a0011016 |work=JPL Solar System Dynamics |publisher=Jet Propulsion Laboratory |accessdate=6 October 2019}}
  • "11016 Borisov (1982 SG12)". JPL Solar System Dynamics. Jet Propulsion Laboratory. Retrieved 6 October 2019..

StarryGrandma (talk) 02:50, 7 October 2019 (UTC)

1. Can't use your first example as the Template:Cite web documentation says that the title parameter must contain the page title, not the search string. 2. Following the example of Ethnologue, the citation could look like this:

"Borisov" at JPL Small-Body Database

Or, perhaps:

Search: "Borisov" at JPL Small-Body Database

— UnladenSwallow (talk) 03:14, 7 October 2019 (UTC)

Including |title=JPL Small-Body Database Browser as the title is also unsatisfactory as the page content changes according to the search parameters. What is the point of emitting the correct metadata for |title= when referring to a page with uncertain content. It only makes sense to refer to the naked search page, i.e. without a search. |title= needs to be accompanied by something else if it is to be useful or have an alternative parameter that can be linked without emitting metadata.   Jts1882 | talk  06:06, 7 October 2019 (UTC)

|title= needs to be accompanied by something else if it is to be useful… Hence my query parameter proposal above. The metadata output can be modified accordingly to make sense. — UnladenSwallow (talk) 08:39, 7 October 2019 (UTC)

I note that the examples in the OP don't include an acecss date, which they surely should. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:32, 10 October 2019 (UTC)

Thanks, Andy. I have omitted |access-date= in this post for brevity. I always include it in citations I add to articles. — UnladenSwallow (talk) 00:54, 11 October 2019 (UTC)

It's also worth noting that "JPL Solar System Dynamics" isn't a magazine, newspaper or journal. It's an organization, and in any mainstream footnoting style, such as Chicago Manual of Style, ALA or MLA, it's not italicized. In any mainstream form, it would go under "publisher=". --Tenebrae (talk) 21:52, 15 October 2019 (UTC)

1. The first sentence that greets the visitors to the website is: Welcome to the JPL solar system dynamics web site. The header above says: JPL Solar System Dynamics. It's pretty clear that "JPL Solar System Dynamics" is the name of the website, not the publisher. The publisher is "Solar System Dynamics Group", as can be inferred from the footer: This site is maintained by JPL's Solar System Dynamics Group. Therefore, "JPL Solar System Dynamics" goes into website, not publisher. 2. I share your displeasure at the {{cite web}} automatically italicizing the website parameter. As you can see from the discussion above, I am against it. However, that's what the template is currently doing. — UnladenSwallow (talk) 14:24, 26 October 2019 (UTC)

I think we're in general agreement. I'm seeing the title at the top of page at that website as Solar System Dynamics, published by the NASA Jet Propulsion Laboratory, specifically the division titled Solar System Dynamics Group. Similarly the database/aggregator Rotten Tomatoes is the publisher of, say, the critics aggregation for Zombieland: Double Tap. Yet because RT has a parent company which editors put "publisher=," editors then put RT in the "website=" field even though RT is not italicized in citations anywhere else in the mainstream. It's like italicizing Marvel Comics when no one else does simply because its parent company is Disney.

It's a growing issue that a "cite organization" template would solve. That way we have "organization=" and, if someone wants to be didactic, "parent=". --Tenebrae (talk) 18:50, 27 October 2019 (UTC)

I would guess that at least half of the 400,000-odd articles with a taxobox (i.e. articles about organisms or groups of organisms) cite at least one taxonomic database. For CS1 style citations, the general approach seems to be to use "cite web" with whatever kind of url displays information about the taxon linked to a title parameter that includes the taxon name, regardless of whether it shows up as a page title, and then to use the work/website parameter for the database. There are many specialized templates that generate a citation template in this way, although my experience is that direct use of citation templates is more common. Peter coxhead (talk) 21:42, 17 November 2019 (UTC)

cite ebook

Template:Cite ebook redirects here, but I don't see any directions for how to cite an ebook. I'm trying to reference something in an ebook I have on Amazon, but the reader in read.amazon.com doesn't display pages, only locations. And, those locations change depending on what the font size is. How can I either a) get the actual page from this, or b) properly cite the location in a way that everyone can access the same place in the book? Thanks. —scarecroe (talk) 12:15, 18 November 2019 (UTC)

Some ebooks do not have real page numbering, as you have noticed. Using |chapter= is probably your best option. You could also use |quote= to quote a short passage; that would help readers locate the passage you are citing. – Jonesey95 (talk) 13:30, 18 November 2019 (UTC)

Another option is find the cited passage in the real book (check Google Books or Archive.org which have a lot of scans) then cite that edition instead. It makes it easier to find and link to scanned copies for verification. -- GreenC 14:17, 18 November 2019 (UTC)

Thanks for the tips. Shame there's no universal method, but I'll make do. —scarecroe (talk) 15:23, 18 November 2019 (UTC)

Detecting misunderstood cite_book parameters

Apparently some users (see example) have misinterpreted location to mean "location of info within book" and pages to mean "number of pages in said book" (which in fact checks out). I doubt any amount of documentation could have prevented these errors, but these do both seem like immediate red-flag input detectable from the module. Perhaps we could show a warning/error message and/or populate appropriate tracking categories for:

• Any location containing numeric digits (and/or "page(s)"/"pg(s)"/"p(p)" as a whole word) is probably bogus. If any books are published at Area 51, the government would neither confirm nor deny it.
• Any plural pages parameter containing only one integer is suspect:
  • Determining whether this page number appears to be on or about the last page (which, you know, is probably blank), resembling the book's total number of pages according to available databases, would be left as an exercise—quite possibly a bot task.
  • Otherwise if it numerically seems to be a valid content page number (whether or not we can actually read it to confirm that it supports the preceding statements), said bot should rename the parameter to the singular form page to avoid further confusion.

I've stumbled upon oddities like this a few times before, often enough to wonder how many other articles are affected, hence this request. ―cobaltcigs 14:45, 23 November 2019 (UTC)

This insource search confirms (as we've always known) that editors are boundlessly clever in how they misuse cs1|2 templates. When I ran the search it returned 14k+ hits for any text containing digits assigned to |location=.

I think that |pages= with only a single integer is not something that we should seek to alarm on. If I'm not mistaken, there are bots or citation tools that for their own convenience write |pages= and then fill it with whatever rather than do the work of determining which of |page= or |pages= is appropriate to the citations. They do this because cs1|2 renders single-integer |pages= correctly:

{{cite book |title=Title |pages=6}} → Title. p. 6.

But, because Citation bot is out there tweaking citations, perhaps the maintainer of that tool can be persuaded, for the purpose of correct semantics, to add this task to their list of things the bot does. Determining 'last page' is out of scope for Module:Citation/CS1.

—Trappist the monk (talk) 16:19, 23 November 2019 (UTC)

I've hacked Module:Citation/CS1/sandbox:

{{cite news/new |date=17 March 2013 |author=Miroff, Nick |page=27 |title=Pope's activity in Dirty War Draws Scrutiny |location=Sec. 1 |agency=Washington Post |work=Chicago Tribune}}

Miroff, Nick (17 March 2013). "Pope's activity in Dirty War Draws Scrutiny". Chicago Tribune. Sec. 1. Washington Post. p. 27.{{cite news}}: CS1 maint: location (link)

The improper use of |location= in the above template adds a maint cat Category:CS1 maint: location.

—Trappist the monk (talk) 19:44, 23 November 2019 (UTC)

Another plea for a licence parameter

Hi there, I have read the previous discussion on the topic[6][7], and I would like to reopen the discussion on whether we should add a licence parameter to the template, to signal reusable material. Previous opposition argued that the only purpose of citations is to satisfy WP:V, and thus access only. I would like to argue that reusability is another facet of WP:V, allowing to not only cite, but add material we could not otherwise (such as drawings, figures, tables, etc). Furthermore, in addition to be a useful signal for other Wikipedia editors, it IS also useful for readers, that are nowadays as much creators as they are data consumers, Wikipedia being an epitome of this change in Internet usage. --Signimu (talk) 20:43, 25 November 2019 (UTC)

The long answer in no. Citations are not creative endeavors, one of the problems is exactly the fact that Wikipedia allows pretty much anyone creative license (ok) including being creative with facts (not ok). There is no reusability in verifying an article claim, because we have no way of knowing what any particular wikitext claim will be. There are already options in various CS1/2 templates to cite items such as drawings and tables. I'm afraid this is the wrong forum for what you are asking. It is not within the scope of citation practice here. 24.105.132.254 (talk) 14:38, 26 November 2019 (UTC)

No, not yesterday, not now, not ever. The purpose of citations is to verify things, not to advertise which source is free to re-use, and which is not, down to the specifics terms of the license. Headbomb {t · c · p · b} 14:54, 26 November 2019 (UTC)

I'm of the same opinion that citations don't traditionally indicate the license of the source, nor should they. That said, I work with a set of organizational committee minutes that we've scanned. They've been added to Commons where we can and transcribed to Wikisource. I've then added entries for each document to Wikidata, and they're being tagged on WD as public domain (where applicable) in addition to tagging the scans on Commons and the transcriptions on Wikisource as PD. Someday when we decide to offer the option to link a citation to the Wikidata Q number, that's really the full extent of what we should do to indicate license status. Imzadi 1979 → 18:41, 26 November 2019 (UTC)

'editor' or 'editors' as author names

In poking through Category:CS1 maint: extra punctuation I've been finding a lot of crap. Some of it should have been detected before we implemented the extraneous punctuation test. Specifically, we should have been looking for 'editor' and 'editors' as the only content of an author parameter. I have remedied that in the sandbox:

Cite book comparison

Wikitext	{{cite book|date=2009|edition=2nd|first1=Paul De Vos ... [et al.],|isbn=0-387-68489-1|last1=editors|location=Dordrecht|publisher=Springer|title=Bergey's manual of systematic bacteriology.}}
Live	editors, Paul De Vos ... ,; et al. (2009). Bergey's manual of systematic bacteriology (2nd ed.). Dordrecht: Springer. ISBN 0-387-68489-1. {{cite book}}: |last1= has generic name (help); Explicit use of et al. in: |first1= (help)CS1 maint: extra punctuation (link) CS1 maint: multiple names: authors list (link)
Sandbox	editors, Paul De Vos ... ,; et al. (2009). Bergey's manual of systematic bacteriology (2nd ed.). Dordrecht: Springer. ISBN 0-387-68489-1. {{cite book}}: |last1= has generic name (help); Explicit use of et al. in: |first1= (help)CS1 maint: extra punctuation (link) CS1 maint: multiple names: authors list (link)
from Arthrobacter monumenti

I've also added a test to catch the bracketed 'et al'. —Trappist the monk (talk) 00:38, 2 December 2019 (UTC)

Cite book comparison

Wikitext	{{cite book|date=2009|edition=2nd|first1=Paul De Vos ... [[et al]]|isbn=0-387-68489-1|last1=editors|location=Dordrecht|publisher=Springer|title=Bergey's manual of systematic bacteriology.}}
Live	editors, Paul De Vos ... ; et al. (2009). Bergey's manual of systematic bacteriology (2nd ed.). Dordrecht: Springer. ISBN 0-387-68489-1. {{cite book}}: |last1= has generic name (help); Explicit use of et al. in: |first1= (help)
Sandbox	editors, Paul De Vos ... ; et al. (2009). Bergey's manual of systematic bacteriology (2nd ed.). Dordrecht: Springer. ISBN 0-387-68489-1. {{cite book}}: |last1= has generic name (help); Explicit use of et al. in: |first1= (help)
from Arthrobacter monumenti

Also catches the todo that was in the module, but leaves behind a sad pair of brackets. --Izno (talk) 00:50, 2 December 2019 (UTC)

The warning seems fine, but the render appearance of things seem to have taken a hit in the sandbox. Headbomb {t · c · p · b} 00:54, 2 December 2019 (UTC)

I'm not overly concerned about the rendering of an obviously malformed template (there is always the hope that someone will actually look at the rendering and see that sommat's amiss and render the necessary aid). Still, I have added a wikilink pattern that doesn't orphan the outer brackets.

—Trappist the monk (talk) 01:28, 2 December 2019 (UTC)

GGKEY

Should we add an optional parameter for GGKEY, a google book identifier? [8]. It can be found in some google books and added to the article, for example see Battle of Hel where the code was included in the refs (I think through this tool). --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 03:12, 2 December 2019 (UTC)

What does the GGKEY do or represent? Would it link to something? The web page you link to above says GGKEYs are only used internally within Google. We don't typically privilege a vendor's internal key, especially when identifiers like OCLC and ISBN ids are almost always available. When I do a web search for "GGKEY 8THUT9WAPTR", the GGKEY added to that article, I don't get anything except WP and WP mirrors. – Jonesey95 (talk) 04:07, 2 December 2019 (UTC)

I don't disagree, just wanted to raise it in case someone would find something more that merits this being useful, particularly AFAIK nobody has raised GGKEY in our discussions here before. I am totally wine with concluding we don't need to include it. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 05:02, 2 December 2019 (UTC)

Sounds good to me. It is useful to have a discussion on the record. I found a Worldcat record and an ISBN for that book, so I don't think there is a demonstrated need for a GGKEY identifier (yet). – Jonesey95 (talk) 05:11, 2 December 2019 (UTC)

I don't think that there is much use in cs1|2 for GGKEYs. As far as I can tell there is no easy way to get from the GGKEY to the source. GGKEY redirects to Google Books where there is no mention of GGKEYs in that article's text. So, perhaps |id=GGKEY:... should be detected and flagged with a maint cat so that these can be removed. This insource search found about 1900 instances.

The author of the google books reftag tool appears to be around occasionally. If we decide that there isn't a good use for GGKEYs, perhaps the author will be willing to tweak the tool so that it doesn't continue to add them when google doesn't have an isbn for the book.

—Trappist the monk (talk) 14:28, 2 December 2019 (UTC)

Time to fix "In: <title>"?

Regarding the problem where "In:" is not prepended to a title when no editor is specified (previous discussion), where Kanguole demonstrated a fix that was not implemented due to press of other work: could we have that implemented now? ♦ J. Johnson (JJ) (talk) 22:34, 5 October 2019 (UTC)

@Kanguole? ♦ J. Johnson (JJ) (talk) 20:54, 10 October 2019 (UTC)

To recap, the proposal was that

{{cite book |chapter=Chapter |first=Ann |last=Author |title=Book}}

which is currently formatted as

Author, Ann. "Chapter". Book. {{cite book}}: |last= has generic name (help)

should instead be

Author, Ann. "Chapter". In Book.

This compares with the formatting of

{{cite book |chapter=Chapter |first=Ann |last=Author |title=Book |editor-first=A.N. |editor-last=Editor }}

as

Author, Ann. "Chapter". In Editor, A.N. (ed.). Book. {{cite book}}: |last= has generic name (help)

It seems a clear improvement to me. The editor is flagged by "(ed.)", while "In" indicates a chapter in a book. Kanguole 22:07, 10 October 2019 (UTC)

Yes. Not the least because it is not the editors that are "in" a book, but the chapters. ♦ J. Johnson (JJ) (talk) 20:47, 11 October 2019 (UTC)

Really? Who is the muddled one? Look at where 'In' is placed in this rendering:

{{cite book |author=Author Name |chapter=Chapter Title |editor=Editor Name |title=Book Title}}

Author Name. "Chapter Title". In Editor Name (ed.). Book Title. {{cite book}}: |author= has generic name (help)

Left to right:

Author name list precedes "Chapter Title", indicating that Author(s) is/are credited for "Chapter Title"

'In' introduces the Editor name list

Editor name list precedes Book Title, indicating that Editor(s) is/are credited for Book Title

The citation means exactly that Author's chapter is 'In' Editor's book. It does not say that Editor is in the book.

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

The author's chapter is "in" a book described by "Editor Name (ed.) Book Title". If there is no editor, the chapter is "in" a book described by "Book Title". Kanguole 23:27, 11 October 2019 (UTC)

Original discussion is at Help talk:Citation Style 1/Archive 59 § Proposal for an "in-title" ("In" + title) parameter. I think that I am opposed to this for the reasons I stated in the original discussion.

—Trappist the monk (talk) 22:27, 10 October 2019 (UTC)

That was a wide-ranging discussion, but on this specific proposal I believe your argument that was that "In" marks editors, and is therefore superfluous if no editors are given. I've responded to that above. Kanguole 08:02, 11 October 2019 (UTC)

T: Your premises in the previous discussion were incorrect, and your grasp of the context muddled. It seems your underlying objection is simply WP:IDONTLIKEIT. Do we need to revisit this? ♦ J. Johnson (JJ) (talk) 20:55, 11 October 2019 (UTC)

If you believe me to be incorrect and that my grasp of the context muddled, show me where I am incorrect and muddled. Just claiming these things for whatever reasons you might have is not sufficient to persuade me to change my position. You are right, I don't like it, but I don't like for the reasons that I've stated. Tell me what you think is muddled or incorrect, and I will attempt a clearer explanation.

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

Trappist: In the previous discussion you stated (at 16:02, 22 Aug) that:

(1) The current "cs1|2 rendering has been in use for a long, long time and, so far as I know, has not caused our readers untoward confusion",

(2) "this proposal seems like a fix for something that isn't broken", and

(3) "The proposed use case ... would result in incomplete citations with, consequently, incomplete metadata."

In the previous discussion I explained why this is needed: there is an exceptional challenge in citing reports of the IPCC, especially in articles where there are dozens of such citations. Now I can't speak to what you may know about citing IPCC reports (though I suspect you have little or no experience in such cases), nor whether these details have "caused our readers untoward confusion" (how would we know?). But I can speak for editors: judging by the results it is a challenge for those who try, and with previous results being inconsistent, inadequate, and confusing. Strictly speaking your statement is correct (you don't know), but irrelevant. What is incorrect is the unstated premise that you would know if there was "untoward confusion", and the inference that therefore there isn't any problem.

As explained previously, I have developed a way of handling these cases which is fully in accord with standard citation practice, except for one little detail: cs1|2 omits the "in". That is broken.

You argue that the proposed use "would result in ... incomplete metadata". Not really, but refusing to supply "in" is not going to force inclusion of editors. It will result — and currently does — in corruption of the title metadata where editors include "in" in the title itself. You might note that in my approach the top level citation is complete in every way, including the editors (up to four).

More could be said, but let's thrash out the foregoing first. ♦ J. Johnson (JJ) (talk) 23:41, 11 October 2019 (UTC)

I don't think that there is anything wrong or muddled in any of the three statements of mine that you quote.

1. yeah, I don't know for absolute sure that the current rendering has not caused our readers untoward confusion. Do you know for absolute sure that readers have been caused untoward confusion? Without evidence either way, perhaps this point is moot.
2. I stand by that; it was the conclusion of the preceding paragraph
3. I stand by this too. In your original post you wrote: I have instances of multiple chapters in books where it is preferable to not list the book's editors in each chapter's citation, yet I would like to indicate that the chapter is "in" a larger work. This is the proposed use case. Omitting pertinent information because it is 'preferable' (the why of that has not been explained) is improper because the resulting metadata are incomplete.

I have no experience citing IPCC reports. But, let us examine the current state of Global warming and in particular AR5 Working Group I Report. In the previous discussion you provided an IPCC-preferred chapter citation so let us look at that report's citations.

• in the main book citation:
  • you name IPCC as the author; IPCC does that in their 'preferred' citation. As a communal effort, I suppose that IPCC is, in a way 'the' author but the book is really the product of the editors and its various contributors.
  • you use |series= to hold what in IPCC's citation is a subtitle. I presume that you are doing this as a way of avoiding the URL–wikilink conflict error that would arise from wikilinking part of the subtitle (...[[IPCC Fifth Assessment Report|Fifth Assessment Report]]...) when |url= has a value. This is problematic because the value assigned to |series= is made part of the citation's metadata in &rft.series misleading readers who consume the citation via the metadata into thinking that the report is part of a series named:

    Contribution of Working Group I to the Fifth Assessment Report of the Intergovernmental Panel on Climate Change

  • you set |harv={{harvid|IPCC AR5 WG1|2013}} as an anchor link from § Notes and from the various chapter citations in § Sources. I suspect that you also did this because the first four authors of "Summary for Policymakers" and "Technical summary" are the same and the first three editors of the book are also the same so Stocker et al. (2013) is ambiguous.
• in IPCC AR5 WG1 Summary for Policymakers you omit the authors entirely; not clear why
• in all of the individual chapter citations you use this construct:

  |title={{Harvnb|IPCC AR5 WG1|2013}} → IPCC AR5 WG1 2013 → [[#CITEREFIPCC_AR5_WG12013|IPCC AR5 WG1 2013]]<span class="error harv-error" style="display: none; font-size:100%"> harvnb error: no target: CITEREFIPCC_AR5_WG12013 ([[:Category:Harv and Sfn template errors|help]])</span>

  which makes the title in the rendered citation and in the citation's metadata be IPCC AR5 WG1 2013; not the title of the book. We have discussed this peculiar use before; you ignored me then, I expect that you will continue to do so now.

The above may be fully in accord with some (not named) standard citation practice, but not with cs1|2.

In the previous conversation I asked: Can this not be handled by a mixture of {{sfn}} templates pointing to {{harvc}} templates that point to a single full citation template? You answered: no, this can NOT [quote of my question redacted]. You did not say why. At User:Trappist the monk/sandbox/ipcc I have used {{harvnb}}, {{harvc}}, and the original {{cite book}} (slightly modified) to do what it is that I think you want.

—Trappist the monk (talk) 15:26, 12 October 2019 (UTC)

Responses:

1. That's right: you don't know that there isn't a problem in regard of the readers. And therefore you should not claim that. However, there is a problem in regard of our editors, which is evident in various confused attempts to cite IPCC reports. (I can state from personal experience that the confused and incomplete state of some of these attempts impairs verification, and it is reasonably inferred that there is confusion amongst that small slice of the readers that attempt to go to the source.)

2. So we will have delve into your prior statements. For now I will just summarize what I (and Kanguole) have said: what is "in" a book is the chapters, not the editors. More on this later.

3. "Omitting pertinent information" and "incomplete metadata" seems to be the essential core of your complaint. (Right?) As for explaining why: I did so explain in the previous discussion. Perhaps that explanation was inadequate? Or perhaps you didn't read it? Well, I provide the same example as before of a typical citation as requested by the IPCC:

Stocker, T.F., D. Qin, G.-K. Plattner, L.V. Alexander, S.K. Allen, N.L. Bindoff, F.-M. Bréon, J.A. Church, U. Cubasch, S. Emori, P. Forster, P. Friedlingstein, N. Gillett, J.M. Gregory, D.L. Hartmann, E. Jansen, B. Kirtman, R. Knutti, K. Krishna Kumar, P. Lemke, J. Marotzke, V. Masson-Delmotte, G.A. Meehl, I.I. Mokhov, S. Piao, V. Ramaswamy, D. Randall, M. Rhein, M. Rojas, C. Sabine, D. Shindell, L.D. Talley, D.G. Vaughan and S.-P. Xie, 2013: Technical Summary. In: Climate Change 2013: The Physical Science Basis. Contribution of Working Group I to the Fifth Assessment Report of the Intergovernmental Panel on Climate Change [Stocker, T.F., D. Qin, G.-K. Plattner, M. Tignor, S.K. Allen, J. Boschung, A. Nauels, Y. Xia, V. Bex and P.M. Midgley (eds.)]. Cambridge University Press, Cambridge, United Kingdom and New York, NY, USA.

The problem here is a useless glut of metadata. As I said before (highlighting added): That's only ten editors and 34 authors (and I have several instances of over 50 authors); it does not include the chapter's contributing authors and review editors. This is a surfeit of "fullness", a useless glut of metadata that paralyzes the grasp of essential information. (A demonstration: how quickly can you scan that citation and pick out which chapter it refers to?)

It should be noted: that citation is intended to carry full details about BOTH the chapter AND the volume (book). Which is fine for a single standalone citation, but what I am dealing with is contexts where multiple chapters are cited from a given volume. In such cases repeating the volume information in each chapter's citation is not just useless redundancy, it buries the vital information (such as which chapter) in that useless information.

The "omission" here is not of editor metadata (other than being trimmed to only four editors), but of useless redundancy. That you want (?) the COinS data for a chapter to include all of the information for the volume is pointless because in most of these cases the chapter is not available separately, but only in the volume. (But of course there is an exception.) (If the emission of seemingly incomplete COinS data is a concern, then give us an option to suppress that.)

The rest of your comments are mainly an attack on the method I have developed, and not really relevant to the issue here of "in", but I will address them briefly.

• That you believe "the book is really the product of the editors and its various contributors" is wonderful, and totally immaterial: that the IPCC attributes some content as collectively "IPCC" (instead of to individual authors and editors) is their call, not yours.

• Any problems with the use of |series= can be discussed, but is off-topic for this discussion.

• Yes: the "IPCC AR5 WG1 ..." form is used because of multiple problems with use of author strings. Example; "Stocker et al. 2013a" and "Stocker et al. 2013b" are essentially useless, giving no information other than there are two cites to what ever report that came out in 2013.

• EVERY "Summary for Policymakers" is credited to the IPCC (and not to the drafting authors and editors) because this is per the IPCC, which is because these are "tweaked" by the governments.

• Re the rendering of "title": are you referring to the metadata for the chapter, or the book? The title of the latter is Climate Change 2013: The Physical Science Basis. The use of |title= in the chapter citation is as a link to the book, and can be considered as incorporating by reference all of the details of the book, including the title, subtitle, editors, publisher, isbn, other isbn, and doi. The use of a symbolic link more clearly identifies for both readers and editors the target of that link.

My reference to "standard citation practice" refers to nearly universal practice (see any style manual): chapters get an "in", even without editors. That cs1|2 does not do this is the deviation that I am trying to get fixed.

Your suggestion to use {{harvc}} is unworkable, and grotesque. Even if it produces an acceptable result, it introduces an additional, more complicated template, where many WP editors find the simpler harvnb somewhat challenging. It is grotesque in requiring the use of this additional template in every case (and additional instruction in its use), all of which would be avoided by a simple, one-time fix to cs1|2.

Your belief that "in" should be contingent on having editors I will have to address later, as I am out of time now. ♦ J. Johnson (JJ) (talk) 23:46, 12 October 2019 (UTC)

1. I have never said that en.wiki editors aren't confused when it comes to citing IPCC chapters

2. Yet another thing I have never said: I have never said that editors are in books; I have said that authors's (possessive) chapters are in editors's (possessive) book.

3. pretty much, because someone somewhere is relying on what metadata is present in an en.wiki article to be correct; IPCC AR5 WG1 2013 as a book title is definitely not the correct book title and there are no other bibliographic details, ISBN, publisher, etc that can be used as an aid to figuring out what the cryptic title really is

Yeah, IPCC's preferred citation format is a bit overmuch. By the way, it was not hard for me to skip over the author name-list to find the chapter title; it's right after the date. cs1|2 provides |display-authors= and |display-editors= as a way of reducing the quantity of author and editor names in the rendered citation; you have been using these parameters to, apparently, aid the the grasp of essential information.

Yeah, I know that you want to cite individual chapters of a source. I know that repeating the volume information in each chapter's citation is not just useless redundancy, it buries the vital information (such as which chapter) in that useless information. I know that you want to omit useless redundancy by which you mean volume or book bibliographic detail. I get that. This is precisely why {{harvc}} was created and it does it well without the need to misuse cs1|2 by use of invented book names and omitted bibliographic detail that results in incomplete and wrong metadata. If the emission of seemingly incomplete COinS data is a concern, then give us an option to suppress that. You have it: {{harvc}}.

To your bullet points:

• perhaps it is; perhaps it isn't; if IPCC truly considered itself the author, it would be so stated on the report's title page
• still subtitle in |series= is a misuse of |series= so is pertinent to this discussion about improper metadata
• am I to understand that you disapprove of any short-form citation that uses lowercase letter CITEREF disambiguation?
• I cannot speak to the validity of your claim; show me something that supports your claim
• I get that you are using the {{harvnb}} in the cs1|2 template's |title= (book title) parameter to link to the book's full citation so that you don't have to repeat all of the book's bibliographic detail for every chapter. My claim is that such use in a cs1|2 template is wrong because each cs1|2 chapter citation produced by this method generates flawed and incomplete book metadata.

"standard citation practice" refers to nearly universal practice (see any style manual) This seems to me to be an other-stuff-exists argument. cs1|2 has never inserted in between the rendered value assigned to |chapter= and the adjacent rendered value assigned to |title=. I see no reason why that practice should be changed.

Causing cs1 to insert 'In' (or 'in' with cs2) between chapter and title fixes nothing. For your use case, the chapter citations would still produce flawed and incomplete book metadata. Your characterization of {{harvc}} as grotesque; what does that mean? You don't like how it looks? {{harvc}} is more complicated than {{harvnb}}. But, for the most part, {{harvc}} uses the same parameter names as cs1|2 and {{sfn}} / {{harv}} templates. {{harvc}} adds |in1=–|in4= and |anchor-year=. Editors who can work out how to use cs1|2 and the short-form templates can work out how to use {{harvc}}. The en.wiki editor confusion is not fixed by the addition of 'in' between chapter and title.

—Trappist the monk (talk) 19:29, 14 October 2019 (UTC)

An arbitrary break where we go into whether "In" is ever "superfluous"

Trappist:

Let us consider your other contention, that cs1|2 "isn't broken" because (given chapter and title) the "in" should be contingent on specifying one or more editors.

Your statement that cs1|2 "isn't broken", the "conclusion of the preceding paragraph", goes back to our previous discussion last August, where you said: "'In' without editors, to me, seems to be extraneous because |authorn= (and aliases) identify the author(s) of the entire book so saying explicitly that "Chapter title" is 'In' Book title written by Author(s) is overkill or clutter."

I find this quite muddled because in the cases at hand there are not any "author(s) of the entire book". The chapters have authors (and also editors), and the books (volumes) have editors; there is NO "Book title written by Author(s)". That statement (the core of your argument!) needs considerable rework.

I am further baffled by how "'In' without editors" could be "extraneous". (I will be quite impressed if can provide a sensible explanation.)

On the otherhand, is it not clear to you that the factual nature of a chapter being in a book – both physically, and in the abstract concept of a work – is not altered by the specification, or not, of any attributes such as authors or editors, or titles, publisher, etc.? ♦ J. Johnson (JJ) (talk) 19:56, 13 October 2019 (UTC)

cs1|2 isn't broken. I stand by that overkill or clutter statement. Taking the simple case, a book authored by a single author. The book has a title: Book Title. The book is subdivided into chapters. We want to cite "Chapter 6". Because there is only one author, that author must be the author of "Chapter 6" so there is no point in saying in a cs1|2 citation that "Chapter 6" is in Book Title. Of course it is; that is obvious. There is no need to state the obvious.

The cases at hand are edited works where chapters are contributed by a variety of authors. Another simple example, a book assembled by a single editor. The book has a title: Book Title. The book is subdivided into chapters. Each chapter is written by a separate author: Author A wrote "Chapter 1", Author B wrote "Chapter 2", etc. We want to cite Author B's "Chapter 2" so cs1|2 names Author B and "Chapter 2" which is in Editor's Book Title. Because cs1|2 now adds an '(ed.)' or '(eds.)' suffix to editor name lists it might be argued that rendering 'in' when there is an editor name list is unnecessary. I have more sympathy for that argument than for adding 'in' between adjacent chapter and book title. And, I have to wonder: if it is necessary to have 'in' text between chapter and book title, isn't it also necessary to have 'in' text between journal/magazine/newspaper article and the adjacent journal/magazine/newspaper name?

The proposed change to Module:Citation/CS1 applies to my first simple example where there is no named editor, which as I have just attempted (yet again) to explain, is superfluous. The cases at hand, because the book has editors, has the 'in' text between the cited chapter and the editor list as it should. Leaving out the editor list as you want to do tells cs1|2 that there are no editors so it doesn't include the 'in' text.

cs1|2 has never supported the notion of chapter editors.

—Trappist the monk (talk) 19:29, 14 October 2019 (UTC)

In your first paragraph you describe "the simple case, a book authored by a single author." (Whether authorship is a single person or entity, or plural, is immaterial, so let us agree that "author" includes "authors".) The essential character of your simple case is not "a single author", but no editors, and also no division of authorship within the work.[Removed duplicated content.]

Then you state that "The proposed change[applies to]where there is no named editor", which you describe as "superfluous". And you conclude: "Leaving out the editor list as you want to do tells cs1|2 that there are no editors so it doesn't include the 'in' text."

And there is the heart of the problem: you equate "no editors specified" (that is, no list of editors) with both no editors, AND no division of authorship. Both of those equivalences are false. (I direct your attention to the sample IPCC citation above, where the editors are listed in brackets, which indicates they are optional. I also direct your attention to the last line of my last comment: "the factual nature of a chapter being in a book [...] is not altered by the specification, or not, of any attributes such as authors or editors ...." Do you disagree?)

Your belief seems to be that listing of one or more editors is required to show when a chapter's authorship does not apply to the containing work. My view is that "In" communicates that. Which is not "superfluous" in the simple case of unitary authorship and no editor, because it is not used in that case. That is not because no editor is specified, but because authorship of the chapters is the same as for the whole work. Where chapters have different authorship it is quite legitimate to cite them without specifying the editors (if any), but "In" is required. In that regard cs1 is in fact broken.

And no, "In" is not used between the title of articles and the name of the journal or periodical because it is understood that the attributed authorship applies solely to the article.

In summary: you err in making "(eds.)" do the work of "In". ♦ J. Johnson (JJ) (talk) 23:58, 14 October 2019 (UTC)

The simple case I described was as I described it: a single author; nothing more, nothing less. Because it is a single author example, there can be no division of authorship unless it is somehow possible to subdivide the single author into halves or quarters or whatever. Had there been an editor for my single-author example, I would have so stated. The point of that example is to show that 'in' text is superfluous because the single author is understood to be the author of both the chapter and the book.

It is true that the proposed change to Module:Citation/CS1 would insert unnecessary 'in' text between chapter title and book title when the template does not have an editor name list. cs1|2 cannot discriminate between a book that has no editors and a book with editors whose names are not present in the template. It is the responsibility of the en.wiki editor to correctly fill cs1|2 template parameters or to use some other citation method.

That IPCC elects to bracket the volume's editor list does not necessarily indicate that the editor list is optional; it may just be a stylistic choice. And, IPCC's preferred citation form is neither here nor there because we are talking about cs1|2. You have evidence to support your claim that the IPCC editor list is optional in their preferred citation form?

I have never claimed that a chapter is not in a book. I have claimed that it is not necessary to state the obvious: it is obvious when the author of the chapter is the same as the author of the book (the single author example).

Yes, listing of one or more editors is required to show when a chapter's authorship does not apply to the containing work because without that list, the cs1|2 citation is incomplete. 'In', without an editor name list does not indicate that a chapter's authorship does not apply to the containing work. Inclusion of 'in' text between chapter title and book title as an indicator that editors have been omitted, as it appears you want, will misrepresent all chapter citations where the chapter author and the book author are the same. The proposed change to Module:Citation/CS1 would include 'in' text between chapter title and book title. Your statement that the simple case of unitary authorship and no editor, because it is not used in that case is contradictory to that reality because the 'in' text would be included in the unitary author case.

Where chapters have different authorship it is quite legitimate to cite them without specifying the editors (if any), but "In" is required. In that regard cs1 is in fact broken. False and false. In a cs1|2 template, naming an authored chapter in an edited work where the editor(s) has/have been omitted, misleads readers into thinking that the chapter author(s) is/are the author(s) of the book; the cs1|2 template appears to Module:Citation/CS1 as the unitary author case. cs1|2 cannot discriminate between a book that has no editors and a book with editors whose names are not present in the template. The insertion of 'in' text between the authored chapter and the edited book title (editor list omitted) says nothing about an omitted editor name list. For this, cs1|2 is not broken. The rendering of the citation that should have editors is flawed because an en.wiki editor did not include the necessary editor name list; that is not the fault of the template but is the fault of the en.wiki editor.

—Trappist the monk (talk) 17:54, 15 October 2019 (UTC)

Your "subdivide the single author into halves or quarters or whatever" is bullshit, and shows just how muddled you are, and even ridiculous. There is no question here of dividing authors; the "division" refers to authorship – that is, the work, and thereby the attribution, of one, or more. authors.

Regarding your "simple case": back where you said "there is no point in saying in a cs1|2 citation that "Chapter 6" is in Book Title", I had actually agreed with that statement, and presumed that you would not say "this chapter is in this book". But the only way "In" would be included is if you did "say" (specified) "|chapter=Chapter 6" in the {cite book} template.

Which is wrong. In this kind of simple case you do not create a full citation (using cs1|2) for a chapter; the full citation is for the book as a whole. Citation of a specific chapter, or pages, or any other part, is specified as an in-source location. If you are not using short-cites (or similar) that data can be appended to the template along the lines of {{cite book |year= 2001 |author= Author |title= Book Title |isbn= 99999}}, Chapter 6, p. 110. Note: no |chapter=, therefore no "In" in the result. A chapter rates a full citation only where it is separately citeable, usually because of different authorship.

I may provide some explicit examples, but it looks like I don't have time for that today. ♦ J. Johnson (JJ) (talk) 19:41, 16 October 2019 (UTC)

Clearly you did not understand my use of the words single author to mean just that; a 'single author' means: 'one author'. I meant the 'subdivision' phrase to show that division of authorship is a meaningless concept then there is only one (a single) author.

Your quote of my statement misrepresents what I wrote. (I did fix the markup in the {{tq}} template). Here is the whole sentence: Because there is only one author, that author must be the author of "Chapter 6" so there is no point in saying in a cs1|2 citation that "Chapter 6" is in Book Title. Of course I would say: "this chapter is in this book" because it is. The proposed change to Module:Citation/CS1 would insert, unnecessarily, 'in' text between the chapter's title ("Chapter 6") and the book's title (Book Title).

Why would an en.wiki editor not specify |chapter= in a {{cite book}} template? It is done quite a bit. Here is an insource search for articles using {{cite book}} with |chapter= but without any of the |editor...= parameters. Because it is an insource search, the number of articles returned by the search is quite variable so the number of articles found by the search is likely quite a bit less than the actual number of articles that meet the search criteria.

Which is wrong. ... Really? Says who? Were it wrong in cs1|2 to specifically cite a chapter in a book's full citation, then cs1|2 would not allow en.wiki editors to do just that by providing and supporting the |chapter= parameter and its various aliases. Yeah, if en.wiki editors want, they may choose to append chapter and other in-source locator information after a cs1|2 template but why would they want to do that? That is guaranteed to produce inconsistently styled citations and to contribute to the citation maintenance headache.

—Trappist the monk (talk) 18:19, 17 October 2019 (UTC)

I can think of three different situations where I would cite a chapter.

1. The chapter as a whole supports the claim in the Wikipedia article, and none of the considerations my points 2 and 3 apply. I would use "at=Chapter 3" or similar.
2. The authorship of the chapter is different than the editorship of the whole book. I would use "chapter= The Moon" or the like.
3. The chapter is available as a convenience link, but the book as a whole is not. The authorship of the book and chapter are identical. I would use a hand-typed citation spelling out the titles of both the book and the chapter, with the chapter hyperlinked to the convenience link (since the templates don't provide for this scenario).

Jc3s5h (talk) 20:45, 17 October 2019 (UTC)

Are you sure? Hyperlinking to a chapter's text someplace on the internet is why cs1|2 support |chapter-url= (and its aliases). Here's an example:

{{cite book |author=Author |date=2019 |chapter=Chapter |chapter-url=//example.com |title=Title |location=Location |publisher=Publisher}}

Author (2019). "Chapter". Title. Location: Publisher. {{cite book}}: |author= has generic name (help)

—Trappist the monk (talk) 20:54, 17 October 2019 (UTC)

I hadn't noticed the chapter-url parameter. Jc3s5h (talk) 17:43, 18 October 2019 (UTC)

Which works fine if you are citing only one chapter. If you are actually citing the whole book, use of |chapter= and |chapter-url= would be incorrect. In that case the availability of one (or more?) chapters (your #3) is information best appended to the template. ♦ J. Johnson (JJ) (talk) 22:44, 18 October 2019 (UTC)

I have fully understood that your "simple case" is of a single author. I also understand – perhaps you do not? – that whether authorship is attributed to a single author, or multiple authors, is immaterial, as it makes no difference in the case presented. Your "subdivide the single author into halves or quarters or whatever" comment shows that you do not understand that my "division of authorship" is not over the domain of authors, but over the domain of what portion of the work is attributed to the identified author or authors.

The concept of division of authorship is not meaningless even in this simple case, because it allows for an affirmation of no such division. It also provides a basis for distinguishing a not quite so simple case of a book attributed to a single author, yet some part of it has different authorship.

And I have not misrepresented your statement. I quoted the part of your statement with which I agree. I left out your preliminary bit because it is muddled (and arguably wrong), and is immaterial to your point that "there is no point in saying ...", in order to focus on the key point.

As to saying explicitly that "this chapter is in this book": now you say "[o]f course" you would, though previously you said "there is no point}" in saying so. I think you were right the first time. Given a book with unitary authorship (that is, with no division, and regardless of whether "author" is singular or multiple), there is no point in listing all of the constituent parts. As long as the various parts have the same authorship (and date and publisher), they are presumed to be a single work. For which there should be a single full citation.

The actual point in referencing the chapter is to specify the in-source location of the content referred to. (Right?) But here you err (along with a thousand or so others) making the full citation refer to a specific part. Consider this: if you wanted to cite Chapter 1 and Chapter 6 of a book, would you invoke {cite book} twice, making two full citations? Or would you use |chapter=Chapter 1, Chapter 6? In such cases appending such information to the template is more sensible than trying to make the template handle all of that.

Where a chapter (or other part) should be specified in a full citation is where that is distinctly citable in its own right (typically because of differing authorship), not simply part of a larger source. E.g.: where a book is attributed to "Smith", we don't repeat that information for each chapter (let alone each page!), as each part is presumed to inherit the attributes of its parent. But if one chapter is actually written by (or with) "Jones", that needs to be said. This is where the citation should be "Chapter by Jones in Book by Smith".

"[I]nconsistently styled citations" already exist, are exactly what I am trying to address (particularly with the IPCC reports), so it rather amazing that you raise every possible objection to what I am doing. ♦ J. Johnson (JJ) (talk) 23:25, 17 October 2019 (UTC)

(edit conflict)

Apparently you don't. I think you are tying to read more into the simple example than is there. In the simple example, there is no subdivision of authorship; none; nada; the whole thing is the responsibility of the single author; every chapter, every verse, every page, every paragraph; all attributable to a single author; no other person gets credit for any of the simple example.

You want cs1|2 to add 'in' text between chapter title and book title for all book citations. There is no point to doing that. It is obvious that the chapter is in the book; it must be because it is all part of the same citation. When I read that citation, I can see that the chapter is in the book without your proposed change beating me over the head: "see, look here, this chapter is in this book." Don't need that.

You misrepresent me because the whole sentence says something different from how you are construing that little snippet.

Yes, of course I would. Given the evidence of a cs1|2 citation with |chapter= and |title= and without your proposed change to insert 'in' text between the two parameter renderings, it is obvious that the chapter is part of the book. There is no point to the extraneous addition of 'in' text between chapter and book title; they are both in the same citation.

I suppose then that you are opposed to the use of pagination or any other forms of in-source locators in full citations? I don't think that I have seen |chapter=Chapter 1, Chapter 6 or the like in the wild. Such use would probably be contrary to the requirements of the metadata which appears to want one chapter item per &rtf.atitle= key. Editors usually write separate full citations using |chapter= for these kinds of cases or they crowbar the chapter titles into multiple {{sfn}} or {{harv}}-family templates. Appending multiple chapter names to the end of a full citation works only to the extent that the chapters are only visible to those who consume cs1|2 template visually; the chapter information is wholly lost (as it is with all short cites) to those who consume these cs1|2 citations via the template's metadata. Keeping the chapter in the cs1|2 template at least gets the metadata consumer in the general vicinity of the information being cited. And yep, free-form text inserted in the <ref>...</ref> tags is free-form text that one en.wiki editor will write one way, and other en.wiki editors will write in other ways. That is a recipe for inconsistency.

"Chapter by Jones in Book by Smith" is supported:

{{cite book |title=Book by Smith |author=Smith |contribution=Chapter by Jones |contributor=Jones}}

Jones. "Chapter by Jones". Book by Smith. By Smith.

Yep, I object to your proposed change to Module:Citation/CS1 that would unnecessarily insert 'in' text between chapter title and book title. I am in favor of consistency; tacking in-source locator information onto the end of a cs1|2 template in a free-form manner, as you have proposed here, is not going to do that.

—Trappist the monk (talk) 23:11, 18 October 2019 (UTC)

I have found expert opinion (Chicago Manual of Style) that "In" is never superfluous, but required in all cases where a chapter is cited, even in a single-author book where there is no division of authorship. From the 17th edition:

14.106 Chapter in a single-author book.

When a specific chapter (or other titled part of a book) is cited in the notes, the author's name is followed by the title of the chapter (or other part), followed by in followed by the title of the book.

Similarly for multiauthor books. It appears this is to distinguish chapters, which are always in a work, from parts which are of a work. ♦ J. Johnson (JJ) (talk) 22:55, 18 October 2019 (UTC)

That's nice. cs1|2 is not CMOS; is not APA; is not MLA; is not Bluebook; is not <insert favorite style guide here>. Yeah, sure, cs1|2 may have been influenced by these style guides but cs1|2 is not beholden to them.

—Trappist the monk (talk) 23:11, 18 October 2019 (UTC)

When I referred to "standard citation practice" a week ago you demurred [i.e., implied "the raising of an objection or taking of exception so as so as to delay action"] that these practices were "not named", and not in accord with cs1|2. [15:26, 12 Oct.]. But when I do name an authoritative source your response is that "cs1|2 is not beholden to them." To judge by some of your earlier statements – such as "I see no reason why that practice should be changed" – cs1|2 is beholden to only you, the self-appointed gate-keeper. This is starting to sound like a case of WP:OWN.

And now you have .. YET ANOTHER OBJECTION!! That if editors are allowed to insert free-form text into notes there will be inconsistency (gasp!), which you are not going to allow. Which is quite irrelevant to the change I am requesting, and comes into this discussion only because of your confused understanding of how to handle in-source locators. I have tried to address every objection you have made, but this is getting to be whack-a-mole. Perhaps you should codify your objections in a list, and be done with making them up as you go. ♦ J. Johnson (JJ) (talk) 21:55, 19 October 2019 (UTC)

You declined to name the 'standard' of the citation practice you are using at Global warming; that's ok, it does not really matter except that, whatever that standard citation practice is, it is certainly not in accordance with cs1|2 for the reasons that I have stated.

It is true that your authoritative source is an authoritative source about itself. But, CMOS, as an authoritative source, has no control over MLA (its own authoritative source about itself), nor APA (also its own authoritative source about itself), nor Bluebook (yep, also its own authoritative source about itself), and, therefore, no control over cs1|2. So, yeah, cs1|2, while it may have been influenced by CMOS, as it may have been influenced by MLA and influenced by APA, is not beholden to any of those authoritative sources.

It is true that I see no reason for us to change Module:Citation/CS1 to add 'in' text between chapter title and book title as you would have us do. That opinion does not make cs1|2 ... beholden to only [me] nor does my willingness to defend this opinion make me cs1|2's self-appointed gate-keeper. Such assertions are nonsense. I do not own cs1|2; never have, never will.

If you will recall, you are the one who suggested that If you are not using short-cites (or similar) that data can be appended to the template along the lines of {{cite book |year= 2001 |author= Author |title= Book Title |isbn= 99999}}, Chapter 6, p. 110. Note: no |chapter=, therefore no "In" in the result. From this I understand that you do not want en.wiki editors to use |chapter=, |page=, or the other in-source-locator parameters in a cs1|2 template but, to instead, add that information, free-form, after the template. One en.wiki editor's free-form text will be different from another en.wiki editor's free-form text so, yes, citations adhering to this method will be inconsistent.

—Trappist the monk (talk) 18:55, 20 October 2019 (UTC)

You have a curious way of twisting things around. E.g., I did not "decline" to name a standard, as no one requested such information; that word is misrepresentation.

When I said I had a method "fully in accord with standard citation practice, except for one little detail", I was referring to the general forms and practice of citation that are common amongst essentially ALL citation authorities, such as the ordering and styling of author(s), title, publisher, etc. — which you can confirm by consulting what ever authority you may have at hand. And with which cs1|2 certainly IS "in accordance". The detail at issue here is a certain case where cs1|2 is not "in accord" with itself.

But your complaint here (that I did not name a particular standard) is just more bullshit, because when I do name an authoritative source you assert that it is authoritative only about itself, and assert that it "has no control" over cs1|2. Which is more twisting of reality, as no one claims that the Chicago Manual of Style has any "control" over anything but what the University of Chicago Press publishes. What you reject is the fact that CMS has influence because it is respected for providing a useful, clear, and consistent (as far as can be expected) model for citation, based on over a century of experience. Whereas your opposition is based on ... what? No authority, extremely little experience, just your personal interpretations and preferences of how matters should be.

You see no reason for this change, therefore you won't make this change. That sounds like ownership to me. If not, how about stepping aside and letting someone else make the change? ♦ J. Johnson (JJ) (talk) 21:44, 21 October 2019 (UTC)

The detail at issue here is a certain case where cs1|2 is not "in accord" with itself. How do you reckon that? Your proposal here is to insert 'in' text between chapter-title and book-title. This is something that cs1|2 has never done. How can cs1|2 not [be] "in accord" with itself for this thing that it has never done?

I did write that it is ok that you have not have named the standard that you are using at Global warming. I also wrote that whatever that standard is, it is not cs1|2 but is some other standard. It is true that CMOS has no control over cs1|2. Just because CMOS says to do something some way does not obligate cs1|2 to do the same thing the same way as CMOS would do – vice versa, cs1|2 does not dictate style to University of Chicago Press. Yes, CMOS and the others are influential, they influenced the creation of cs1|2. I have never denied that. When the original authors created the original templates more than a decade past, they chose, for whatever reason, not to insert 'in' text between chapter-title and book-title. I, for one, happen to agree with that choice. My agreement with that choice and opposition to the current proposal is not ownership.

—Trappist the monk (talk) 14:32, 23 October 2019 (UTC)

What??? How can you seriously say that inserting "in" is "something that cs1|2 has never done"? Here is an instance of {cite book} (highlighting added): Author (2000). "Chapter". In Editor (ed.). Book. {{cite book}}: |author= has generic name (help) Do you not see "in" immediately following "Chapter"? QED: cs1 has inserted "in", and your statement that it never does is disproved.

The bottom line of all the rest you just wrote is: 1) you do not accept any external authority, and 2) you "approve" of the way cs!| works now, so are not going to change that. The problem with that first position is that you have not indicated that you accept any authority or expert guidance, showing no basis for your opinion other than undisclosed, personal LIKE. And your "approval" can't be because you think the past work of sacred authors is perfect, because you are constantly changing it. You have also made all kinds of arguments, but they're pretty much all bullshit (like your "never done" argument above, or the "free-form text" argument before it), or just irrelevant. The bottom line to all of this is: you DON'T LIKE the request, and therefore you WON'T ALLOW IT. How is this not an indication of ownership? ♦ J. Johnson (JJ) (talk) 21:47, 24 October 2019 (UTC)

The insertion of 'in' text between chapter-title and editor-name-list is not the same thing as the proposed insertion of 'in' text between chapter-title and book-title. cs1|2 has never inserted 'in' text between chapter-title and book-title which is the proposed change to cs1|2. You will recall that in my first reply to you in this subsection I said that now that the editor-name-list is annotated with '(ed.)' or with '(eds.)', I am more likely to support the removal of the 'in' text in that case because now, the editor-name-list annotation makes the 'in' text somewhat redundant or superfluous.

—Trappist the monk (talk) 15:15, 25 October 2019 (UTC)

So your sense of "between" is without any other text also between, the other text being that about the editors. In that case your previous statement is missing a key qualification, and a more correct statement would be: Cs1|2 has never inserted "in" without also inserting editor(s). Which (with a possible quibble about "never") is my statement of the problem. And your position is, quite simply, "having never done this before, it never should do it." Which is absurd, and not a valid argument.

Your statement that inserting "(eds.)" "makes the 'in' text somewhat redundant or superfluous" further demonstrates that you do not understand the nature and scope of "in": it does not apply to the editors. It applies to the entire containing work (which has attributes of editor(s), title, etc.). Likely you have been confused because the list of editors immediately follows the "in", but that is incomplete; you should parse the range of "in" greedily, not parsimoniously. "Eds." describes the nature of the named persons as "editors". "In" relates the preceding part of the citation – about the chapter, which has a title and possibly zero or more named authors — to the rest of the citation, which has a title, and possibly empty list of named editors. (And I can provide an example of a book with a chapter with different authorship, and no named editors.) "In" relates the chapter to the work, quite independently of whether any editors are named; it is neither redundant nor superfluous.

"In" applies to chapters, and conditioning it on having editor(s) is thus an error. Having never been fixed is not an acceptable argument for should never be fixed. ♦ J. Johnson (JJ) (talk) 00:08, 26 October 2019 (UTC)

Yep, 'in' text without any other text also between chapter-title and book-title is the essence of your proposal and the thing that I oppose as superfluous and unnecessary. It is true that cs1|2 has never inserted "in" without also inserting editor(s). If it makes you happy to write it that way, do so. No. My position is that 'in' text without any other text also between chapter-title and book-title is superfluous and unnecessary; does not convey any information that is not already present in the rendered citation. cs1|2 has never inserted 'in' text between chapter-title and book-title; it ain't broke so it don't need fix'n.

When there is an editor name-list, 'In' text introduces the reader to the editor name-list so that the reader knows not to go into the stacks at the local library and look for the book at the chapter-author's name (the book is the editor's book and so is cataloged by editor's name). This is the only benefit that I can see for keeping the 'in' text with the editor name-list. It was more important when cs1|2 did not include the '(ed.)' or '(eds.)' annotation at the end of the editor name-list. With the annotation, the 'in' text is less important which is why I wrote that annotations [make] the 'in' text somewhat redundant or superfluous.

When there are no editors, and therefore no editor name-list to render, 'in' text does not introduce anything so is superfluous. Writing cs1|2 citation templates without editor name-lists when those templates should have editor name-lists (the apparent underlying rational for this whole proposal) is writing malformed cs1|2 citation templates.

Clearly, you and I are not going to agree. We could go on, I suppose, but unless one of us somehow manages to find and enunciate that perfect argument, neither are going to be convinced to change our positions. With the caveat that I remain opposed to the proposal, you may have the last word if you'd like it.

—Trappist the monk (talk) 00:17, 29 October 2019 (UTC)

Another arbitrary break for "in: title"

The argument that the cs1|2 templates have always done something is not a strong one, partly because the introduction of "(ed.)"/"(eds.)" has changed the context, and partly because the cs1|2 style is a collection of more-or-less arbitrary decisions taken over a long period and fossilized by the extreme difficulty of getting anything changed.

Certainly the above discussion does seem to have discussed aesthetics and different notions of consistency to the point of exhaustion. You are against the change; J. Johnson and I are in favour of it, and we know how to implement it.[9] So unless someone else chimes in, or there is some technical issue, I propose that we make the change. Kanguole 01:03, 29 October 2019 (UTC)

I am persuaded by Ttm's points. :) --Izno (talk) 01:56, 29 October 2019 (UTC)

I do not agree that the impasse between Trappist and I cannot be resolved by anything less than a perfect argument. I also think that (even after two weeks) this discussion is not mature, in that there are a lot of loose ends. Particularly, there are some possibly persuasive arguments that have not yet been presented. Even if Trappist is done with this discussion, it has been long enough that it is unrealistic to expect a reasonable evaluation of the issue without a more succinct statement of the arguments. And the argumentation is incomplete on both sides. (E.g., I can think of at least argument Tappist has not raised.) If everyone agrees that a reasonable resolution can be made as matters stand now, fine, but in the current somewhat inchoate state there could be miscomprehensions. And I think there is still a chance that Trappist could be persuaded. ♦ J. Johnson (JJ) (talk) 19:51, 30 October 2019 (UTC)

Izno: Some of Trappist's points are foolish. Could clarify which points you find persuasive? ♦ J. Johnson (JJ) (talk) 19:43, 2 November 2019 (UTC)

Trappist: Repeating an earlier request: would you mind listing all of your objections? There are so many that I am not certain I haven't overlooked any. ♦ J. Johnson (JJ) (talk) 23:57, 29 October 2019 (UTC)

Summary of the case for this modification

The following summarizes the case for modifying the cs1|2 code so that the insertion of "in:" into a citation is conditioned on specifying a chapter.

It is standard citation practice (as recommended by all major citation authorities) to insert "in:" to indicate that a cited source is part of a larger work — such as a chapter in book — that has different authorship than the cited source. Currently cs12 does this only when one or more editors (presumably of the larger work) are specified. That functionality thus fails for actual and legitimate cases – such as contributions in conference proceedings where the editors that assemble the papers are often not named, or even books where an author includes someone else's work as chapter, but there simply is no editor – and the "in:" is needed despite the lack of any named editors.

There are also cases of works (possibly with a long list of editors) from which multiple chapters are cited, where it is unuseful and even detrimental to repeat all of the details of the work in the citation of every chapter.

In opposition (by Trappist the Monk), it has been argued that cs1|2 is "not beholden" to any of these expert authorities, and therefore they do apply here. That is an unuseful attitude. Such authorities reflect "best practices" based on years of professional experience that would be unwise to ignore, and the use of "in:" in this manner is a standard convention that readers expect.

It has also been argued that "in:" introduces the editor(s), and without a list of editors it is "superfluous and unnecessary". However, the prerequisite that "in:" introduces a list of editors is incorrect. It should be understood as applying to the work, not to just the first detail that describes the work. It might be noted that some citation authorities place the editors after the book title, which shows that the scope and meaning of "in:" is not changed by the ordering of the details of the work.

It has been argued that not specifying any editors "misleads readers into thinking that the chapter author(s) is/are the author(s) of the book...." But that is the point of "in": to indicate that a chapter has different authorship (or editorship) than the work; the problem arises not from a lack of editors, but from a missing "in:". It is precisely this point why "in" should be inserted even when no editors are specified.

The inverse has also been argued, that where the authorship of a chapter is the same as the work (book), inclusion of "in:" implies otherwise, and is extraneous. However, this only happens if |chapter= is specified, which is an improper usage in such cases. Full citations (such as created by cs1|2) cite only the whole source, not the constituent parts. Such cases are presumably where a WP editor is trying to provide an in-source location, which should be done by other means. As has been said before, "that is not the fault of the template". At any rate, an extraneous "in:" does no harm.

Additional arguments of opposition have been made (see the long discussion above), but are not substantive. If there are no further comments I will propose proceeding with the requested modification. ♦ J. Johnson (JJ) (talk) 21:23, 9 November 2019 (UTC)

@Kanguole:: There being no additional comments or objections, I propose we proceed with the requested modification. ♦ J. Johnson (JJ) (talk) 00:15, 13 November 2019 (UTC)

You must not take my silence as approval or even acquiescence. It is not. Neither of us were able to convince the other to change position. Nothing that I have read in your writings here since then has changed my position. Lest my self-imposed silence be misconstrued as approval or acquiescence, I must break that silence to reaffirm my opposition to this proposed change.

—Trappist the monk (talk) 00:36, 13 November 2019 (UTC)

I do not take your silence as approval, and I recognize your position of WP:IDONTLIKEIT. So we will let others decide. ♦ J. Johnson (JJ) (talk) 01:03, 13 November 2019 (UTC)

Trappist the monk's first comment here was "I think that I oppose this change", and his concluding position is that he won't discuss it. In between I have tried to address each of his objections, but he is adamant: he doesn't like it, and won't discuss it. Therefore it is not to be done. He is the boss here, and he has -- spoken? He has not articulated a persuasive argument against. ♦ J. Johnson (JJ) (talk) 21:25, 1 December 2019 (UTC)

Oh darn, I thought you had dropped it. I re-read the discussion a day or two ago because I was prompted earlier, and "I(DON'T)LIKEIT" isn't at all the basis on our side. It boils down to this: You would have us add additional text to every edited (and unedited) book citation where it is only needed essentially in your one and only one basically-super-special case. That's a non-starter. --Izno (talk) 22:29, 1 December 2019 (UTC)

Also, have you tried this: {{cite book |contributor=Contributor |contribution=Contribution |title=Book |author=Author |editor=Editor}}? Displays as: Contributor. "Contribution". Book. By Author. Editor (ed.). {{cite book}}: |author= has generic name (help). Is that somehow insufficient? --Izno (talk) 22:56, 1 December 2019 (UTC)

Full citations (such as created by cs1 This is simply false. --Izno (talk) 23:03, 1 December 2019 (UTC)

Your first assertion, that I "would have us add additional text to every edited (and unedited) book citation ...", is false. This falsity arises in part from an incorrect premise, that the condition for inserting "In:" is whether a "book" (or other work) is "edited", or not. Now most books are edited (whether an editor is credited or not), and if you also include whatever books are not edited, that would cover all of them, right? Which is ridiculous, and not at all what I requested. So let's presume you meant "where an editor is specified". Even in that case citation of a book does not require "In:". (What exactly is the book "in"? Itself??)

"In:" is used universally (arguably by everyone except Wikipedia) to indicate that a chapter (paper, etc.) is contained in a larger work (generally with different authorship). Such works often specify one or more editors, but sometimes not. That is a point missed by whomever wrote the pertinent code here when they made "In:" unnecessarily contingent on specifying an editor. (In addition to having |chapter= and |title=, though off-hand I don't recall the exact details here.) What I have requested is NOT going to "add additional text to every edited (and unedited) book citation"; it adds "In:" only in those "super-special cases" where chapter and title have been specified and it should be included, but is not, for lack of a named editor.

And it appears you have not been paying attention through the past discussion. I am not dealing with trivial toy examples like yours, but industrial-strength cases where multiple chapters are cited from a volume ("book"), which if done your way would result in citations like the following, where everything past the point indicated is ponderously, and needlessly, redundant, making the key points harder to find:

{{Cite book |year= 2014 |chapter= Chapter 1: Point of Departure |chapter-url= https://archive.ipcc.ch/pdf/assessment-report/ar5/wg2/WGIIAR5-Chap1_FINAL.pdf |display-authors= 4 |first1= V. R. |last1= Burkett |first2= A. G. |last2= Suarez |first3= M. |last3= Bindi |first4= C. |last4= Conde |first5= R. |last5= Mukerji |first6= M. J. |last6= Prather |first7= A. L. |last7= St. Clair |first8= G. W. |last8= Yohe < Authors of the chapter |pages= 169–194 Everything below here applies to the volume > |title= Climate Change 2014: Impacts, Adaptation, and Vulnerability, Part A: Global and Sectoral Aspects |series= Contribution of Working Group II to the Fifth Assessment Report of the Intergovernmental Panel on Climate Change |author= IPCC |author-link= IPCC < Author of the volume. |display-editors= 4 |editor-first1= C.B. |editor-last1= Field |editor-first2= V.R. |editor-last2= Barros |editor-first3= D.J. |editor-last3= Dokken |editor-first4= K.J. |editor-last4= Mach |editor-first5= M.D. |editor-last5= Mastrandrea |editor-first6= T.E. |editor-last6= Bilir |editor-first7= M. |editor-last7= Chatterjee |editor-first8= K.L. |editor-last8= Ebi |editor-first9= Y.O. |editor-last9= Estrada |editor-first10= R.C. |editor-last10= Genova |editor-first11= B. |editor-last11= Girma |editor-first12= E.S. |editor-last12= Kissel |editor-first13= A.N. |editor-last13= Levy |editor-first14= S. |editor-last14= MacCracken |editor-first15= P.R. |editor-last15= Mastrandrea |editor-first16= L.L |editor-last16= White |publisher= Cambridge University Press |place= Cambridge, United Kingdom and New York, NY, USA |isbn= 978-1-107-05807-1 |url= https://www.ipcc.ch/site/assets/uploads/2018/02/WGIIAR5-PartA_FINAL.pdf }}

There are other challenges with these sources (such as the volume also having an author), but the key point for this discussion is that that long list of editors pertains to the volume, not the chapter, and omitting it should not suppress the "In:". ♦ J. Johnson (JJ) (talk) 23:48, 2 December 2019 (UTC)

PMID: updated PubMed website, URL scheme

An updated version of PubMed has been released, will become the default in spring 2020, and will ultimately replace the legacy version. It has a new web interface, including a new URL scheme with prefix https://pubmed.ncbi.nlm.nih.gov/ + PMID + /, though I don't know where this is documented. It's a cleaner, more responsive website, and should be the default here. See: Collins, Marie (18 November 2019). "The New PubMed is Here". NLM Technical Bulletin (431): e3. ISSN 2161-2986. int21h (talk · contribs · email) 03:27, 6 December 2019 (UTC)

Thanks for this note, int21h. Pinging User:Mvolz (WMF) for the mw:citoid service, User:RexxS in case this might affect any Wikidata-enabled templates, and User:Matthiaspaul for the {{pmid}} template. Whatamidoing (WMF) (talk) 06:21, 6 December 2019 (UTC)

Module:Citation/CS1/Configuration/sandbox updated:

Cite journal comparison

Wikitext	{{cite journal|journal=Integrated Environmental Assessment and Management|pmid=16639905|title=Actinides in Deer Tissues at the Rocky Flats Environmental Technology Site}}
Live	"Actinides in Deer Tissues at the Rocky Flats Environmental Technology Site". Integrated Environmental Assessment and Management. PMID 16639905.
Sandbox	"Actinides in Deer Tissues at the Rocky Flats Environmental Technology Site". Integrated Environmental Assessment and Management. PMID 16639905.

—Trappist the monk (talk) 12:00, 6 December 2019 (UTC)

Awesome. Also notice that the website gives a Location response header to forward to the URL with an ending "/", i.e. https://pubmed.ncbi.nlm.nih.gov/16639905 is forwarded to https://pubmed.ncbi.nlm.nih.gov/16639905/. This is also the format given in its permalink button located on the page. It also appears to rewrite the URL to be more descriptive, using the article title, but I don't know how it's doing that. I don't know how much any of that matters. And before this gets pushed, being such an important template, we should consider confirming the URL scheme, and if all else fails consider contacting the PubMed team about it. Thanks all. int21h (talk · contribs · email) 12:34, 6 December 2019 (UTC)

I suspect that we don't care if the pmid url has a trailing slash. {{pmid}} has been updated, and does not include a trailing slash

{{pmid|16639905}} → '"`UNIQ--templatestyles-00000165-QINU`"'[[PMID (identifier)|PMID]] [https://pubmed.ncbi.nlm.nih.gov/16639905 16639905] → PMID 16639905

If there are to be problems with the new url, there are now some 8k articles using the new url so that should give us some sense of confidence that all is or is not well in the pmid world.

—Trappist the monk (talk) 13:33, 6 December 2019 (UTC)

MR numbers not rendering properly

In the following cite journal, the id should render as MR2108435 (with no space between the MR and the number, the way these numbers are universally used in the mathematical publications from which they come, including in the review database to which they refer, and the way {{MR}} correctly renders them) but instead a space is included. Has this been broken recently, because I don't remember seeing this bug before?

• Giaro, Krzysztof; Kubale, Marek (2004). "Compact scheduling of zero-one time operations in multi-stage systems". Discrete Applied Mathematics. 145 (1): 95–103. doi:10.1016/j.dam.2003.09.010. MR 2108435.

Regardless of whether this is a new regression or an old bug it should be fixed. Think of it this way: suppose you used a template that for whatever reason produced a visible link to this page, "Help talk:Citation Style 1", but the template you used formatted it as "Help talk: Citation Style 1" rather than its proper name because whoever wrote that template somehow thought that Wikipedia namespaces looked better with a space after the colon, even though we all know that's not the proper name. Or if that's not drastic enough, suppose that some space-happy template editor decided that urls should be shown in an expanded form that puts spaces around each set of slashes. Would you be happy? —David Eppstein (talk) 07:02, 21 November 2019 (UTC)

This possibly dates back to sometimes in 2009 to 2011, when identifiers were streamlined into CS1/2 templates. The 2009 discussion address spacing specifically, which settled on unspaced. So maybe it happened through a subsequent code refactoring, e.g. [10]. Headbomb {t · c · p · b} 11:01, 21 November 2019 (UTC)

MR without a space character was added to {{citation/identifier}} (used by {{citation/core}}) with this edit. A   was added with this edit which was, apparently, unchallenged. Comparing {{citation/core}} rendering with current Module:Citation/CS1 rendering:

Cite journal comparison

Wikitext	{{cite journal|doi=10.1016/j.dam.2003.09.010|first1=Krzysztof|first2=Marek|issue=1|journal=Discrete Applied Mathematics|last1=Giaro|last2=Kubale|mr=2108435|pages=95–103|title=Compact scheduling of zero-one time operations in multi-stage systems|volume=145|year=2004}}
Old	Giaro, Krzysztof; Kubale, Marek (2004). "Compact scheduling of zero-one time operations in multi-stage systems". Discrete Applied Mathematics 145 (1): 95–103. doi:10.1016/j.dam.2003.09.010. MR 2108435.
Live	Giaro, Krzysztof; Kubale, Marek (2004). "Compact scheduling of zero-one time operations in multi-stage systems". Discrete Applied Mathematics. 145 (1): 95–103. doi:10.1016/j.dam.2003.09.010. MR 2108435.

Module:Citation/CS1 briefly used a plain-space separator character but has used a   since this edit in April 2013. So, not a recent change.

Editor David Eppstein must have been aware that cs1|2 differed from {{MR}} because of this revert of an edit where the edit summary of the reverted edit noted that it ...breaks format alignment with WP:CS1/WP:CS2... I can find no discussion here or at Template talk:Citation nor in their archives subsequent to that reversion to indicate that either Editor in that {{MR}} dispute bothered to notify anyone that cs1|2 should perhaps be changed.

For myself, I'm not sure that we should change. Running a wikilink directly against a weblink without a separator might be misleading to readers. The separator makes it obvious that there are two links there (the standard link colors are, to my eye, insufficiently different to distinguish one link from another.

—Trappist the monk (talk) 12:57, 21 November 2019 (UTC)

The solution is obvious: restore the consensus version which is unspaced. The addition of the space was undiscussed. This doesn't require an RFC. Headbomb {t · c · p · b} 13:21, 21 November 2019 (UTC)

I concur with Headbomb. XOR'easter (talk) 14:27, 21 November 2019 (UTC)

Anyway, I fixed it. Should be fine now. Headbomb {t · c · p · b} 15:02, 21 November 2019 (UTC)

Nope, apparently I fixed the 'old' version. Oh well, LUApocalypse/template protection strikes again. Headbomb {t · c · p · b} 15:03, 21 November 2019 (UTC)

It looks like you might eliminate the space, for testing purposes, by modifying Module:Citation/CS1/Configuration/sandbox to remove the nbsp from MR's "separator" variable. It would, as TTM says below, make the identifier rendering inconsistent, arcane, and potentially confusing for casual readers of articles. – Jonesey95 (talk) 17:20, 21 November 2019 (UTC)

In what sense is it less inconsistent, arcane, and confusing to make up our own formatting for this identifier rather than using the same formatting that everyone else who uses this identifier uses for it? —David Eppstein (talk) 18:20, 21 November 2019 (UTC)

It is confusing to place two links immediately adjacent to one another without an intervening space. They look like a single link. – Jonesey95 (talk) 19:00, 21 November 2019 (UTC)

The fix for that is to eliminate the link to the Wikipedia article on the identifier type and just make it all one link to the MR entry, not to make up new and unknown-outside-Wikipedia formatting for MR identifiers. —David Eppstein (talk) 19:04, 21 November 2019 (UTC)

That is not a fix because it makes |mr= even more inconsistent with all of the other identifiers because all of the other identifiers have links to articles that explain the identifier; as they should.

—Trappist the monk (talk) 19:11, 21 November 2019 (UTC)

The proposed change will make |mr= inconsistent with all other identifiers because, at present, all identifiers have something (either a : or  ) between the identifier's en.wiki article link and the identifier's target link. The proposed change is arcane because only those who participate in this discussion will understand why, if the change is made, the en.wiki article link and the target link are allruntogether. The proposed change can cause confusion for the casual reader, for whom identifiers are already obscure, because the lack of a distinct separation can result in mis-clicks of either the description link or the identifier target (because they are allruntogether) and land the reader in an unexpected place.

—Trappist the monk (talk) 19:11, 21 November 2019 (UTC)

Thinking about this reminds me of the PMCID and the PMC prefix discussion where we chose to ignore the official NIH recommendation (PMCID: PMC#####). Now here we have a proposal to follow someone else's recommendation. While I think that the wikilink should be separate from the weblink for reasons that I have stated, additionally, we should not be internally inconsistent in how we treat identifiers and their associated wikilinks. The proposed change will make |mr= inconsistent with other identifiers.

I will revert the change to {{citation/identifier}}. That template is maintained as a record of how-things-were when we transitioned to Module:Citation/CS1 so should not be modified.

—Trappist the monk (talk) 16:01, 21 November 2019 (UTC)

Consistancy between identifiers is much less important than presenting the information following the standards of the format. We could write 'arXiv 1301.1146', but the actual format is 'arXiv:1301.1146'. Regardlesss, the space has been introduced without dicussion, against prior consensus, and is inconsitant with {{MR}}, and should be reverted. Headbomb {t · c · p · b} 20:10, 21 November 2019 (UTC)

I don’t know whether it matters much that there is a space but if a *controversial* change was implemented without a discussion, the correct procedure is roll-back the change. —- Taku (talk) 22:53, 23 November 2019 (UTC)

History:

2010-02-28 – |mr= identifier added to {{citation/identifier}} without a space character between the en.wiki article link and the identifier's target link

2012-05-05 –   inserted between the en.wiki article link and the identifier's target link

2013-04-07 – Module:Citation/CS1 changes from plain space character to  ; this is in the overlap period where cs1|2 transitioned from {{citation/core}} to Module:Citation/CS1

at {{MR}} a short-lived edit dispute occurs between two editors wherein the edit summaries of two edits refer to the discrepancy in rendering style between cs1|2 and {{MR}}

2017-08-22T23:13 – this breaks format alignment with WP:CS1/WP:CS2 as well as instantiations using parameters {{{2}}}...{{{9}}} and {{leadout}}} (Module:Catalog lookup link inserts   between the en.wiki article link and the identifier's target link)

2017-08-23T00:04 – this is not how MR ids should be displayed; if some other template does it wrong then fix it too. And when would you ever need multiple ids?

2019-11-21 – this discussion begins

The time between 2012-05-05 when the   was inserted in {{citation/identifier}} and 2019-11-21 when this discussion began is 7 years, 6 months, and 16 days. I am not aware of any complaints about how cs1|2 renders |mr= in that 7.5 year period except for the brief dispute at {{MR}} which did not get raised here at cs1|2. That suggests to me that the 2012-05-05 change was not controversial.

—Trappist the monk (talk) 00:18, 24 November 2019 (UTC)

(edit conflict) Changes that are controversial in the short term should be reverted, but a change that has been in place for seven years can be assumed to have consent, and should not be reverted without discussion, especially in a widely used template. That discussion is what we are having now. – Jonesey95 (talk) 01:42, 24 November 2019 (UTC)

Then let's presume that {{MR}} has consensus as the more-actively monitored one and bring CS1/2 inline with it and the consensus of the active discussions from 2009-2011. Headbomb {t · c · p · b} 04:42, 24 November 2019 (UTC)

Headbomb, that would be an invalid presumption. {{MR}} has fewer than 30 watchers and just 755 transclusions. – Jonesey95 (talk) 05:59, 24 November 2019 (UTC)

That is no different than [11]. Headbomb {t · c · p · b} 06:01, 24 November 2019 (UTC)

It seems extremely likely that the low number of uses of {{MR}} is in large part due to bots running around converting it into |mr= parameters. It means nothing. —David Eppstein (talk) 06:15, 24 November 2019 (UTC)

Suggestion (somewhat clumsy): Tooltip over the cs1 id rendering it without space. 98.0.145.210 (talk) 14:36, 24 November 2019 (UTC)

Not sure that there is a benefit to doing that. Here is a mockup:

<span title="tool tip text here">[[Mathematical Reviews|MR]][https://www.ams.org/mathscinet-getitem?mr=2108435 2108435]</span>

MR2108435

In the mockup, the tooltip provided by MediaWiki overrides the tooptip provided by the <span> tag. And, in an actual implementation, what is the tooltip text?

—Trappist the monk (talk) 14:51, 24 November 2019 (UTC)

Well, it is clumsy. Obviously the code would have to pass the id as a variable and concatenate the label with the id by removing the space after MR. I was thinking of something conceptually similar to {{Hover title}}, but that is a poor example. I am also aware that tips are discouraged for accessibility purposes. 72.43.99.138 (talk) 17:18, 24 November 2019 (UTC)

In this project to build an encyclopedia it is our top duty not to make up stuff. We simply report what is as it is. Since the official and long established MR format is without a space, we must use this format as well. Everything else is wrong and must be regarded as a typographical error. Thanks, David, for bringing up this topic. --Matthiaspaul (talk) 11:37, 7 December 2019 (UTC)

We have recently rejected such logic at this discussion linked by Ttm already. There are other concerns at place here; WP:SEAOFBLUE is I think salient above any such "we must use it as elsewhere" (which you assert is correct). --Izno (talk) 14:51, 7 December 2019 (UTC)

Count me firmly on the side favoring a space to avoid the sea of blue issue. Imzadi 1979 → 17:20, 7 December 2019 (UTC)

I like the spaced variant as well, but IMO personal preferences are completely irrelevant when it comes to falsification of facts. In analogy to what WP:MOSTM recommends for trademarks, we would be free to choose a style if there would not be an established standard, but MRs have always been written without space (except for the few cases where someone made a mistake). If we want to be taken serious as an encyclopedia we have to stick to the facts, and not invent new ones. We are not here to WP:RIGHTGREATWRONGS, we do WP:NOTLEAD, but follow.

WP:SEAOFBLUE is, IMO, a non-issue, because it's a matter of the rendering in the frontend (not something that is our business), that is, it is an issue that should (and easily could, if it would actually be regarded as a larger problem) be addressed in the browser. In most browsers the pre-selected link is shown either underlined or inverse (regardless if selected by mouse, keyboard or touch pad), so there is no risk to confuse a link with an adjacent link. --Matthiaspaul (talk) 20:27, 7 December 2019 (UTC)

Unhelpful error message

• {{cite ssrn|last1=Dichev|first1=Ilia D.|last2=Janes|first2=Troy D.|title=Lunar Cycle Effects in Stock Returns|year=2001|doi=10.2139/ssrn.281665}}

gives

• Dichev, Ilia D.; Janes, Troy D. (2001). "Lunar Cycle Effects in Stock Returns". {{cite SSRN}}: |ssrn= required (help); Unknown parameter |doi= ignored (help)

There should be a better error message for this. Headbomb {t · c · p · b} 21:16, 7 December 2019 (UTC)

Fixed in the sandbox; needs help text and category which I'll do later:

{{cite ssrn/new|last1=Dichev|first1=Ilia D.|last2=Janes|first2=Troy D.|title=Lunar Cycle Effects in Stock Returns|year=2001|doi=10.2139/ssrn.281665}}

Dichev, Ilia D.; Janes, Troy D. (2001). "Lunar Cycle Effects in Stock Returns". {{cite SSRN}}: |ssrn= required (help); Unknown parameter |doi= ignored (help)

—Trappist the monk (talk) 21:41, 7 December 2019 (UTC)

publication-place, place, or location and their proper use

At User talk:Citation bot § Erroneous move of publication-place to location it is claimed that Citation bot improperly replaced |publication-place= with |location= in three {{citation}} templates (this diff).

Template documentation for |place= and |location= is here and template documentation for |publication-place= is here. Also see Help:Citation Style 1 § Work and publisher.

Examples of how cs1|2 currently handle various combinations of |publication-place=, |place= and |location= in {{citation}} (same for cs1 templates):

1. {{citation |title=Title |place=Austin, Texas |newspaper=The Villager}} → "Title", The Villager, Austin, Texas
2. {{citation |title=Title |location=Manhattan |newspaper=The Villager}} → "Title", The Villager, Manhattan
3. {{citation |title=Title |publication-place=The Woodlands, Texas |newspaper=The Villager}} → "Title", The Villager, The Woodlands, Texas
4. {{citation |title=Title |publication-place=Manhattan |place=London |newspaper=The Villager}} → written at London, "Title", The Villager, Manhattan
5. {{citation |title=Title |publication-place=Manhattan |location=Manhattan |newspaper=The Villager}} → "Title", The Villager, Manhattan

In the examples above:

items 1–3 using one of |place=, |publication-place= or |location=, is appropriate here to disambiguate the geographic locale for a particular The Villager

item 4 uses |publication-place= to disambiguate The Villager and |place= to identify where the (missing) author wrote the article (the byline)

item 5 has both |publication-place= and |location= with the same value (Manhattan) so the template renders only |publication-place=

Our article Byline suggests that a byline applies only to newspaper and magazine articles and that a byline identifies an article's author.

If a byline is defined as the author of a news or magazine article (which it seems to be) then shouldn't we:

1. constrain the dual-use of |publication-place= and either of |location= or |place= only to {{citation}} when |newspaper= or |magazine= are set, and to {{cite news}} and {{cite magazine}}?
2. for all other templates (and, for {{citation}} using the other periodical aliases) treat |publication-place=, |location=, and |place= as equal aliases; when two or more are present in a cs1|2 template, emit a redundant parameter error message?
3. because 'byline' is an author name, require an author parameter when |publication-place= and one of |location= or |place= have assigned values?
   • if we do not elect to require an author parameter, we need to tweak the module so that the 'written at' static text is capitalized in {{citation}} template renderings when there are no author-name parameters

—Trappist the monk (talk) 14:36, 3 December 2019 (UTC)

I don't think that these proposed limitations will work. First, I don't know what bylines have to do with anything. While a byline contains the author's name, a dateline often contains the place where the item was written. They are independent of one another; neither requires the other. Second, the documentation for {{citation}} says that |newspaper= and |magazine= are aliases of |work=, as are |website=, |periodical=, and |journal=, so limiting any check to just two of those aliases does not appear to be feasible. It would make different aliases behave differently. Third, I don't see why an item using a {{cite web}} or {{cite journal}} template could not (in theory) have a place where it was written and a place where it was published, although I definitely don't have an example or a good WP:V-related reason to include both pieces of information. – Jonesey95 (talk) 15:24, 3 December 2019 (UTC)

Answers:

1. Our documentation uses the term 'byline' so perhaps that should be changed to 'dateline'?
2. We already make distinctions between the various periodical parameters; for example, we render |volume= and |issue= differently in {{cite journal}} and {{cite magazine}} (and {{citation}} with |journal= or |magazine=) and not at all in {{cite web}} (and {{citation}} with |website=); limiting the check to just magazine and news citations is not at all difficult
3. I would think that a website is always written someplace different from where it is 'published' (is that the location of the 'home office' or the location of the server farm?); except for 'news' websites (which should use {{cite news}}...) does a dateline make any sense? For journals, I suspect that almost all articles are written someplace other than the geographic location of the publisher so a dateline doesn't make much sense there either, does it?

—Trappist the monk (talk) 15:53, 3 December 2019 (UTC)

1. Fixed.
2. Different rendering of parameters in different templates is not the same as treating aliases differently from one another. We do not render |first= differently from |first1=, for example. If we want to have certain parameters stop being aliases of others, we would need to have that discussion, fix all parameter usages so that they were accurate, have never-ending arguments (cf |publisher=/|work= in {{cite web}}), and sometime, years from now, separate the function of the aliases. I don't have the energy for any of that; maybe others do.
3. As I said, "in theory", and I don't have an example. This one might be a non-issue. I thought it might spur someone to remember a relevant example. – Jonesey95 (talk) 17:54, 3 December 2019 (UTC)

Ok, I'm confused. So perhaps what you are suggesting without actually saying it is that |publication-place=, |location=, and |place= should become simple aliases? To get the 'written at' static text, a |dateline= parameter should be invented that only works with {{citation}} (when either of |magazine= or |news= is set) and with {{cite magazine}} and {{cite news}}. More than one of them in a cs1|2 template triggers the redundant-parameter error?

But wait. I spend a lot of time looking at cs1|2 templates and don't often see paired |publication-place= and |location= or |place=. So I decided to see how commonly such pairings are used. If one is to believe these searches, not often:

• location followed by publication place – 65
• place followed by publication-place – 7
• publication-place followed by place – 13
• publication-place followed by location – 9

Pretty rare. So that makes me wonder: do we need this functionality? And further, why do we need dateline / byline annotation anyway? If the purpose of a citation is to help readers locate a copy of the source, why should we be supporting the inclusion of an unimportant tidbit of data that doesn't really help the reader locate a copy of the source? Perhaps the answer to this is to deprecate the support for paired |publication-place= with |location= or |place= and as part of that make all three simple aliases of each other and make |location= the canonical parameter name to reflect use in article space:

• location – 282k
• place – 17.6k
• publication-place – 12k

—Trappist the monk (talk) 00:03, 4 December 2019 (UTC)

If those search results are to be believed, then having multiple locations to accommodate datelines is not useful enough to be worth the difficulties that are created. I suggest creating a maintenance category to track those dual parameters in order to validate the search results. If there are truly only 100 or so articles with dual parameters, we should make them aliases and be done with this unnecessary complexity. People who truly need to indicate a dual location for some reason can place a note outside of the template or use hand-crafted citations. – Jonesey95 (talk) 06:11, 4 December 2019 (UTC)

Sandboxen tweaked and Category:CS1 location test property cat created.

—Trappist the monk (talk) 15:42, 4 December 2019 (UTC)

I think Jonesey95 is correct regarding the handling of aliases. As for the 3rd point, the publisher's location (for the particular work) is the pertinent parameter imo. This is searchable information, and may be an additional path to identifying editions/impressions (a certain work may be styled or assembled differently by imprints of the same publisher based-in/distributed-from different locations). For web-hosted works, the publication place would be the location of the registrant, since registrants are the entities who own the publishing/distribution facility (the domain). If I remember correctly, this goes back some time, the discussion about the place where the work was created came about when citing rare or unique works, manuscripts and certain similar special cases. But I could be wrong on that. 65.88.88.91 (talk) 19:47, 3 December 2019 (UTC)

By the way, this issue also frequently comes up with academic conference proceedings, which typically have both a conference location and a publisher address. If a location parameter is provided, our template formats it as a publisher address, but some suppliers of publication metadata put the conference location in that position while I have also seen other solutions like putting the conference location as part of the title and the publisher location as part of the publisher name. Trying to format this as

{{citation|title=Conference Proceedings|location=Conference Location|publication-place=Publisher Address|publisher=Publisher Title|contribution=Conference Paper Title|author=Author|year=2020}}

produces the totally incorrect formatting

Author (2020), "Conference Paper Title", written at Conference Location, Conference Proceedings, Publisher Address: Publisher Title {{citation}}: |author= has generic name (help)

The location is not where the paper was written, and is not individual to the paper; it was where it was presented, and is an attribute of the proceedings rather than of the paper. The same issue also arises for dates: the date the conference was held and the date its proceedings was published often differ. My usual preference is to either omit the conference location and conference date or list them as part of the conference title (if they really were part of the conference title) but some more formal guidance on this in the documentation might be helpful. —David Eppstein (talk) 00:41, 4 December 2019 (UTC)

I think that this is why we have {{cite conference}}. The proceedings go in |book-title=, the paper in |title=, the place of publication into any of the three |publication-place=, |location= or |place=. If it is necessary or desirable to include the name of the conference and conference location and dates there is |conference= – free form parameter that is not included in the citation's metadata. And for those who use cs2: |mode=cs2.

—Trappist the monk (talk) 01:19, 4 December 2019 (UTC)

Regardless what what the documentation says, the current, overwhelming practice is that |location= is the location of the publisher. If additional specificity is required, then those are the ones that should have dedicated parameters, e.g. |writing-location=, |conference-location=, etc. Headbomb {t · c · p · b} 12:44, 6 December 2019 (UTC)

• I would make location, publication-place, and place all exact aliases, with the meaning of publisher location, and document this more clearly, and do away with the "written at" form completely., it is not generally useful for our purposes. DES ^(talk)_{DESiegel Contribs} 07:33, 9 December 2019 (UTC)

New 979 ISBN Prefixes Expected in 2020

FYI, in case any validation code needs tweaking: https://bisg.org/news/479346/New-979-ISBN-Prefixes-Expected-in-2020.htm --Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:39, 26 November 2019 (UTC)

Nothing that has to be done; cs1|2 already supports the 979 prefix. But, it occurs to me that we might want to strengthen the 979 isbn check so that ismn (979-0...) when assigned to |isbn= emits an error message.

—Trappist the monk (talk) 20:54, 26 November 2019 (UTC)

Module:Citation/CS1/Identifiers/sandbox tweaked:

• {{cite book/new |title=Title |isbn=978-3-943302-34-9}} → Title. ISBN 978-3-943302-34-9.
• {{cite book/new |title=Title |isbn=9791095833017}} → Title. ISBN 9791095833017.
• {{cite book/new |title=Title |isbn=979-0-50226-047-7}} → Title. ISBN 979-0-50226-047-7. {{cite book}}: Check |isbn= value: invalid group id (help)

—Trappist the monk (talk) 14:17, 27 November 2019 (UTC)

979- prefix is "expected" for books published in the USA, but is already being used (and cited on Wikipedia) for a recent subset of books published in France, South Korea, and Italy (which have already exceeded allocations in the 978- prefix). See above section. Just be careful to note that 100% of 978- ISBNs and 0% of 979- ISBNs have a 10-digit predecessor, and disregard almost everything posted by the anon user (from various IPs). ―cobaltcigs 14:40, 27 November 2019 (UTC)

That is not correct. Not all 13-digit 978 ISBNs have a 10-digit predecessor. Also it is not true that 979 ISBNs do not have 10-digit predecessor. Certain non-book educational works fall under the category, and outside the US there may be 979 classifications with 10-digit originals. 72.43.99.138 (talk) 14:54, 27 November 2019 (UTC)

Using the word "predecessor" is shifting the goalposts. There's a one-to-one relationship between ISBN-10 values and 978-prefixed ISBN-13 values. All ISBN-10 values can be converted to a 978-prefixed ISBN-13. All 978-prefixed ISBN-13 values can be converted to an ISBN-10. Not a single ISBN-10 can be converted into a 979-prefixed ISBN-13. Not a single 979-prefixed ISBN-13 can be converted into an ISBN-10. That's what this conversation is about. It's not about a publisher deciding to release a book with one ISBN and later releasing the same title with a different ISBN. --Marc Kupper|talk 07:40, 9 December 2019 (UTC)

access icon css selectors

In January 2019 we changed the selectors for the access icons. That broke {{catalog lookup link}} and Module:catalog lookup link which underlie many of the individual identifier templates (there is a list of these on the template's doc page).

I have tweaked Module:Citation/CS1/sandbox/styles.css to add a less specific selector for use by this and any other templates that might want to use the cs1|2 css.

In this example from Template:catalog lookup link/testcases, links 1, 2, 5, and 8 have access icons:

{{Catalog lookup link/sandbox|1|2|3|4|5|6|7|8|9|article-link=Wikipedia|article-name=WP|link-prefix=//en.wikipedia.org/wiki/|url-access1=free|url-access2=subscription|url-access5=limited|url-access8=registration}}

WP 1, 2, 3, 4, 5, 6, 7, 8, 9

cs1|2 works as it should:

Cite journal comparison

Wikitext	{{cite journal|journal=Journal|pmc=1234|title=Title|url-access=subscription|url=//example.com}}
Live	"Title". Journal. PMC 1234.
Sandbox	"Title". Journal. PMC 1234.

—Trappist the monk (talk) 14:19, 9 December 2019 (UTC)

Thanks! Nemo 14:36, 11 December 2019 (UTC)

Protected edit request on 17 December 2019

Request to fix poor usage: For the quote parameter in the table, please change needs to include to must include. Eric ^talk 13:58, 17 December 2019 (UTC)

 Not done: According to the page's protection level you should be able to edit the documentation page yourself. If you seem to be unable to, please reopen the request with further details. – Jonesey95 (talk) 14:02, 17 December 2019 (UTC)

@Jonesey95: Thanks for looking. I did manage to make the edit just now. Sorry for posting here, not sure what happened before. I must have either hit the wrong link or a link wrongly brought me here to make the request. Eric ^talk 16:08, 17 December 2019 (UTC)

date range in cite-web

is it proper to put a range of dates in {{Cite web}} to show that a website has been online for a certain period of time, or is it best to just use a specific date? —Soap— 15:11, 19 December 2019 (UTC)

Without a specific example, hard to say, but in general, if the page has a specific date (an updated on ... date for example) then use that date; else, don't date and use |access-date= to indicate when you read that page and confirmed that it supported the en.wiki article the uses the citation.

—Trappist the monk (talk) 15:18, 19 December 2019 (UTC)

Okay thanks for the prompt reply. The specific example I'm thinking of is Taxapad, though there could be many more. Somehow a few days ago I stumbled upon this site, and saw in the header a researcher named Dicky Sick Ki Yu (1997-2015). Yes, the name caught my eye, but so did the date range next to the name. I believed that Mr Yu had been a very bright young man who'd unfortunately passed away at the age of 17 or 18, and that the Bug Guide site was paying their respects. But then I looked him up on the wider Internet and found many references to Taxapad on Wikipedia, which was apparently a site run by Mr Yu. Our references list him with the date range (1997-2012). Realizing that it was implausible for a 14 year old to have done all this research, and presumably much of it when he was even younger than that, I figured that the date range must mean something else. So I looked it up and it seems that we are listing the lifespan of the website, not the researcher. That all makes perfect sense to me now. I'm just worried it might confuse other people, especially for sites that have been online for an even longer period of time.

So my question is, should we change all of the Taxapad references to just say 2012? And then apply the same practice to any other instances of {{cite-web}} that have a date range? I dont know of any, but I suspect there are probably more examples on Wikipedia somewhere. —Soap— 16:20, 19 December 2019 (UTC)

It is the purpose of citations at en.wiki to identify and help readers locate the source material that supports text in en.wiki articles. Listing the copyright dates of a relatively short-lived website is not of much use. For Taxapad, I think that |date= can be safely deleted because a date range does not identify a particular point in time when information on that website supported an en.wiki article's text. The handful of Taxapad citations that I looked at do not have |access-date= so we don't really know if the archived snapshot supports en.wiki article text. |date=1997-2015 does not help to pin that down.

—Trappist the monk (talk) 17:11, 19 December 2019 (UTC)

Okay, thank you very much. If our search function is accurate, there are nearly 4000 mentions of Taxapad on Wikipedia, and at least a healthy portion of them have the (1997-2012) text in the date field. So, I cannot do this myself, ... at most I could nibble a bit and get it down to 3800 or so. I will try to see if it can be automated through AWB or some other tool. I suspect, though, it may be low priority because the text as it stands now is not actually wrong. In either case, thank you for your helpful answer. —Soap— 01:14, 20 December 2019 (UTC)

If that date range 1997-2015 is really defining the time this site was online, and if it would be important to indicate the first time the information was available there, a combination of|date=2015 and |orig-year=1997 could be used to indicate this. However, the problem is that it may be difficult now (in 2019) to determine if some specific supporting statement was already online in 1997 (or in some other year before 2015) already under the given link, unless you can find this in archived snapshots. --Matthiaspaul (talk) 06:45, 20 December 2019 (UTC)

ampersands and Vancouver-style name lists

Vancouver style does not support the use of an ampersand between the last two author names in a name list so I have tweaked the module to ignore |last-author-amp= when used with |vauthors=:

Cite journal comparison

Wikitext	{{cite journal|journal=Journal|last-author-amp=yes|title=Title|vauthors=Red R, Brown B, Green G}}
Live	Red R, Brown B, Green G. "Title". Journal. {{cite journal}}: Unknown parameter |last-author-amp= ignored (|name-list-style= suggested) (help)
Sandbox	Red R, Brown B, Green G. "Title". Journal. {{cite journal}}: Unknown parameter |last-author-amp= ignored (|name-list-style= suggested) (help)

—Trappist the monk (talk) 16:25, 23 December 2019 (UTC)