Jump to content

Help talk:Citation Style 1/Archive 50

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 45←Archive 48Archive 49Archive 50Archive 51Archive 52→Archive 55

CS1 maint: Extra text

Module:Citation/CS1 currently places pages in the maintenance Category:CS1 maint: Extra text when a citation parameter contains text that duplicates static text provided by the template itself. The categorization, however, includes talk pages, Wikipedia space pages, process page archives, and related pages on which we would not usually make "corrections" or perform this kind of maintenance. Can/should we adjust the module so that it only finds errors in Main space? I'm assuming this has come up for other maintenance categories but I'm not sure.— TAnthonyTalk 22:10, 3 December 2018 (UTC)

Talk:Avonmouth railway station/GA1 has this sentence:
Also the hidden categories say there's some [[Category:CS1 maint: Extra text|Extra text]] in some of the references.
wherein there exists an improperly marked-up category link. That page is transcluded into Talk:Avonmouth railway station with this:
{{Talk:Avonmouth railway station/GA1}}
Those two pages are the only talk pages ones listed in the category.
There have been discussions here in the past that caused us to leave wikiproject page in the categorization. I see no reason why those pages can't be fixed, especially the wikiproject medicine translation pages.
—Trappist the monk (talk) 22:32, 3 December 2018 (UTC)
My experience with fixing pages in the Wikipedia space and on page archives is that I almost never see an objection. In some cases, careful and documentation-compliant use of the |template-doc-demo= parameter on discussion pages will preserve the error message (which is sometimes being discussed, so should not be removed or "fixed") while removing the error category from the page. – Jonesey95 (talk) 23:19, 3 December 2018 (UTC)
All right, if you both think there won't be an issue with me making the fixes, that's what I'll do. I'll be on the lookout for instances where the error is intentional. Thanks!— TAnthonyTalk 00:52, 4 December 2018 (UTC)

New error: "crap" in the parameters

Not really sure what to call this exactly, but we should have some category to flag citations in need of general cleanup.

One such error is having a comma at the end of a parameter, e.g.

  • |last=Smith,, |title=Do you eat stuff? , |volume=24,

Only |postscript= should end with a comma. Other similar errors could be found, like |last= containing non-hyphen punctuation of some type.

This would populate a general Category:CS1 error: verify parameter syntax, although we certainly could have one category per error flagged, e.g. Category:CS1 error: parameter ending with a comma.

This should also give a link to Citation bot so that people can trigger the fix. Headbomb {t · c · p · b} 17:24, 4 December 2018 (UTC)

I agree with adding an error or maintenance message here at least for the comma pattern, which is common enough, but not with adding a link to Citation bot. That's a separate request and should remain so. --Izno (talk) 05:33, 5 December 2018 (UTC)
It's a separate, but related request. Citation bot can fix those errors, and there's no reason to make things more editor-hostile than they have to be. Headbomb {t · c · p · b} 13:58, 5 December 2018 (UTC)
Be careful with |last=. I can immediately think of Irish names ("O'Reilly" and so on), and foreign-language names may use what appears to be punctuation as a substitute for diacritics. Quite likely to be other traps as well, names are notoriously tricky to allow for. --NSH001 (talk) 17:10, 5 December 2018 (UTC)
Punctuation like ,.;:;?! etc... won't appear in |last= though. Wasn't considering the apostrophe as punctuation, although I suppose it technically is. Headbomb {t · c · p · b} 17:54, 5 December 2018 (UTC)
Well, people enter stuff like |last=Jones, J.G. all the time – even if you and I might think they shouldn't – so that's full stop and comma for starters. Just saying. --NSH001 (talk) 19:56, 5 December 2018 (UTC)
And that's an error that should be flagged! |author=Jones, J.G. is valid, not |last=Jones, J.G.! Headbomb {t · c · p · b} 20:28, 5 December 2018 (UTC)
Doesn't author1 alias to last1? I've been admonished for conversions to use authorN because it messes up lastN. This leaves me confused on what is and isn't acceptable.   Jts1882 | talk  21:02, 5 December 2018 (UTC)

Jts - you're correct aabout the aliasing, see the template documentation, so I can understand your confusion. But basically I'm just making the point to Headbomb about the need to be careful with names, in this case, that comma and full stop will correctly occur in |author= (so we still have to worry about them) instead of incorrectly in |last=. --NSH001 (talk) 21:18, 5 December 2018 (UTC)

Headbomb, I think your initial proposed problem scope (a comma at the end of |last= and a couple other parameters) is valid, but if you keep trying to expand the scope, you'll get objections from WP:CITEVAR types, the whole discussion will spin out of control, "no consensus" will be the result, and you won't get any of what you want. Let's start by limiting the scope to |last= (and all |last#= and their aliases) and maybe |volume= as a test, and limiting the terminal character testing to something like ,?!:; only. If that works, doesn't create a ton of false positives (always remember, names are hard), and there are enough editors willing to fix the errors that are found, we can discuss expanding the scope of the testing, parameter by parameter, with a different list of tests for each parameter. – Jonesey95 (talk) 21:24, 5 December 2018 (UTC)
Yeah, off the top of my head if Katalin É. Kiss gets cited, it would be |last=É. Kiss; I'm sure there are plenty of other instances where there would be punctuation in those fields that would be "fixed" because someone who programmed the bot assumes names to all behave in a certain way. Umimmak (talk) 23:01, 5 December 2018 (UTC)
|last=É. Kiss is fine and valid. It would not be caught by the minimal proposal immediately above, since it does not have invalid terminal punctuation. Commas and periods in |last= (or its alias, |author=) are valid in many cases, so it would be a fool's errand to flag them as errors. – Jonesey95 (talk) 23:43, 5 December 2018 (UTC)
  • I am strongly opposed to adding any links to Citation bot while the bot's operators (in this case its maintainers, through its defaults) do not respect WP:CITEVAR (and at this point it is beginning to look like this is a deliberate tactic specifically to circumvent CITEVAR), and for similar reasons I oppose the addition of any error category that is designed to give the bot a list of articles to run against (as that proposed here is). Names, in particular, are notoriously hard to get right (look up conventions for names among aboriginies some time) and I see no evidence the proposer here has done his homework on them or intends anything but setting a bot loose to do automated edits; which is a wholly inadequate way to deal with the issue.
    I hadn't intended to have any opinion on this proposal, but in plain text: I've lost my ability to trust this tool because every single instance of it being used that has crossed my watchlist lately has ranged from mildly problematic to wildly inappropriate. I'm sure there are responsible users of it doing creat work to improve our citations (which are in dire need of cleanup), but its design as it stands appears to encourage the opposite. Its potential benefits have now for me been outstripped by the damage it causes and I see no signs of its maintainers even recognizing that there is a problem, much less have any interest in fixing or even ameliorating it. --Xover (talk) 19:17, 6 December 2018 (UTC)

accessdate errors

Tracked in Phabricator
Task T211127

Hi, do not know what has happened yesterday but there are a significant number of articles being added to Category:CS1 errors: dates overnight, I would guess about 200. They all appear to be from a change to the way something outputs the |accessdate= as 2018-12-04Tnn:nn:nnZ, ie including a time element. You can see this on this edit. Keith D (talk) 02:15, 5 December 2018 (UTC)

An urgent bug has been filed. – Jonesey95 (talk) 02:53, 5 December 2018 (UTC)
This problem is reportedly  Fixed as of about three hours ago. – Jonesey95 (talk) 14:40, 5 December 2018 (UTC)
Thanks. I think that I have managed catch all of the articles involved. Keith D (talk) 16:49, 5 December 2018 (UTC)
Are you sure of the fix as this change of 18:00, 6 December 2018 caused the same error. Keith D (talk) 21:11, 6 December 2018 (UTC)
Something is goofy there; it looks like a false positive. The date stamp is 2018-12-04T17:52:14Z, which is about two days before the edit was actually saved and one day before the fix was implemented. I suspect that the editor had that paragraph saved in a sandbox or something like that, and pasted it in after it had been sitting around for a couple of days. If you see any date stamps that are after the date stamp of the  Fixed note above, let us know here. – Jonesey95 (talk) 22:22, 6 December 2018 (UTC)

|language= tweaks

Valencian is a language closely related to Catalan and has official status in Spain. But, MediaWiki does not recognize it as a language. There is an IETF language tag, ca-valencia supported by IANA that describes Valencian as a variant of Catalan.

I have tweaked language_parameter() in Module:Citation/CS1/sandbox to accept |language=Valencian and |language=ca-valencia. This tweak uses code already in place to override certain MediaWiki supported names / codes that aren't appropriate for use with cs1|2. There are relatively few instances of |language=Valencian but this change will allow for other similar language codes / names that are, or may be, buried in Category:CS1 maint: Unrecognized language.

Cite book comparison
Wikitext {{cite book|language=Valencian|title=Title}}
Live Title (in Valencian).
Sandbox Title (in Valencian).
Cite book comparison
Wikitext {{cite book|language=ca-valencia|title=Title}}
Live Title (in Valencian).
Sandbox Title (in Valencian).

—Trappist the monk (talk) 15:35, 2 December 2018 (UTC)

And another; ISO 639-2 and -3 names for code crh are Crimean Tatar and Crimean Turkish. crh.wikipedia.org is the Crimean Tatar Wikipedia. But, MediaWiki thinks that the language code crh is:

{{#language:crh|en}} → Crimean Tatar

Because of this I have tweaked the module sandbox to accept Crimean Tatar and render that name when the code is used:

Cite book comparison
Wikitext {{cite book|language=Crimean Tatar|title=Title}}
Live Title (in Crimean Tatar).
Sandbox Title (in Crimean Tatar).
Cite book comparison
Wikitext {{cite book|language=crh|title=Title}}
Live Title (in Crimean Tatar).
Sandbox Title (in Crimean Tatar).

—Trappist the monk (talk) 23:18, 4 December 2018 (UTC)

And more: code cnr is a relatively new ISO 639-3 code for Montenegrin. Module:Citation/CS1/Configuration accommodated that code/name pair until they were added to MediaWiki. MediaWiki now supports cnr / Montenegrin so I have removed the code/name pair from ~/Configuration/sandbox:

Cite book comparison
Wikitext {{cite book|language=Montenegrin|title=Title}}
Live Title (in Montenegrin).
Sandbox Title (in Montenegrin).
Cite book comparison
Wikitext {{cite book|language=cnr|title=Title}}
Live Title (in Montenegrin).
Sandbox Title (in Montenegrin).

I have created a documentation page for |lang= that lists all of the 2- and 3-character codes / language names supported by MediaWiki along with the IETF language tag-like codes / names. These latter are not supported by |language=. Creation of this list allowed me to discover a bug in language_parameter() that caused some cs1|2 templates to be improperly categorized in Category:CS1 maint: Unrecognized language. The improper categorization occurs when a language name has more than one assigned code. For example, MediaWiki assigns Aromanian to the codes rup and roa-rup. The former is the correct ISO 639-3 code while the latter is a made-up code from ISO 639-2 / -5 roa (Romance languages) and ISO 639-3 rup (Aromanian). This formulation is an invalid IETF tag because rup is not registered as a language extension (extlang in IANA language subtag registry). When multiple codes exist for a language in the MediaWiki list, Module:Citation/CS1 may encounter the IETF-like code first, recognize that it isn't a proper code and so place the article in Category:CS1 maint: Unrecognized language. That has been remedied:

Cite web comparison
Wikitext {{cite web|language=Aromanian|title=Trã Armânami|url=http://armanami.org}}
Live "Trã Armânami" (in Aromanian).
Sandbox "Trã Armânami" (in Aromanian).

—Trappist the monk (talk) 14:12, 8 December 2018 (UTC)

changes to Template:Citation Style documentation/publisher

Editor Ans has added {{cite web}}-specific text to the |publication-place= documentation to wit:

'This may be used when the contents of the web being cited is avaiable in only some country.'

One might expect to see in an editor's contributions an immediate justification of such an edit by use of the parameter in that way but, I don't see one there.

So, Editor Ans, why is this change made? Is it necessary? Does it really serve the purpose that you intend?

{{cite web |url=//example.com |title=Title |website=Website |location=Location}}

"Title". Website. Location.

{{cite web |url=//example.com |title=Title |website=Website |publication-place=Publication-place}}

"Title". Website. Publication-place.

{{cite web |url=//example.com |title=Title |website=Website |location=Location |publication-place=Publication-place}}

Written at Location. "Title". Website. Publication-place.

—Trappist the monk (talk) 11:08, 13 December 2018 (UTC)

I have fixed the grammar while waiting for a response from Ans. – Jonesey95 (talk) 12:08, 13 December 2018 (UTC)
The generic descriptions that appear in all relevant cite xxx documentation pages is deficient. It allows one to figure out |location= and |place= are synonyms, but it is not explained why still another related parameter, |publication-place= is needed, or the circumstances where both |publication-place= and |location= would be used for the same publication. Example that uses both, but not in a sensible way:
  • {{cite web| title= Spring Phenomena: 25 BCE to 38 CE | URL = https://aa.usno.navy.mil/faq/docs/SpringPhenom.php | date = 10 August 2017 | last1 = Astronomical Applications Dept. | publisher = U.S. Naval Observatory | location = the closet under the stairs | publication-place = Washington, DC}}
  • Astronomical Applications Dept. (10 August 2017). Written at the closet under the stairs. "Spring Phenomena: 25 BCE to 38 CE". Washington, DC: U.S. Naval Observatory.
Jc3s5h (talk) 13:21, 13 December 2018 (UTC)
At the risk of sounding like the proverbial stuck record: If you see a weakness in the cs1|2 documentation, do some research and fix it.
—Trappist the monk (talk) 14:29, 13 December 2018 (UTC)
The first documentation of |publication-place= seems to be this edit by Gadget850 on 6 May 2013. Looking at the edit history of Module:Citation/CS1, there does not seem to be any edit summary around that time that seems relevant. Looking at the archives of this talk page, there does not seem to be any relevant discussion around that time. Unless Gadget850 can explain what it's for, the meaning of that parameter may be lost forever. Maybe we should document it as a mystery parameter. Jc3s5h (talk) 15:19, 13 December 2018 (UTC)
Plain-text search for "publication-place" constrained to the Template talk namespace in no particular order here:
Template_talk:Citation/core/Archive_10#Agency,_newspaper,_and_location
Template_talk:Citation/Archive_4#location_field_for_citing_a_periodical_when_article_may_be_print_online_only?
Template_talk:Cite_news/Archive_5#Agency,_newspaper,_and_location
—Trappist the monk (talk) 16:40, 13 December 2018 (UTC)

OK, so it's only meant for news stories with a so-called dateline (which really isn't a date). The result is quite grotesque if there isn't an author:

  • *{{cite news | newspaper = Free Press | publication-place = Granville NY | location = Castleton VT | title = Tree Lighting Wednesday | publication-date = December 7, 2018}}
  • Written at Castleton VT. "Tree Lighting Wednesday". Free Press. Granville NY. December 7, 2018.

Jc3s5h (talk) 18:33, 13 December 2018 (UTC)

I've made an attempt at improving Template:Citation Style documentation/publisher‎ Jc3s5h (talk) 19:27, 13 December 2018 (UTC)

Template-protected edit request on 17 December 2018

Since some local wiki use non-Gregorian calendar, so we need to call function from local module (if exists) to convert date to Gregorian calendar as demonstrated in sandbox Ans (talk) 09:58, 17 December 2018 (UTC)

I'm not opposed to this idea but I am opposed to how you have acted to implement the idea. Why did you blow-away all of the changes that are queued for the next update?
The code as written is hardwired to either the sandbox or the live version of Module:Citation/CS1/Local. That needs to be fixed. Is it necessary to do the pcall() each time through the for k, v in pairs()... loop?
If Module:Citation/CS1/Local is to become part of the module suite proper, then the copy at en.wiki must contain sufficient comments and code to give editors at other wikis some idea of how it may be used. The current content of Module:Citation/CS1/Local/sandbox may be appropriate for th.wiki but clearly is not appropriate here or at other non-Thai wikis.
—Trappist the monk (talk) 12:55, 17 December 2018 (UTC)
I reverted the changes to /Configuration also without prejudice to some future implementation. --Izno (talk) 12:58, 17 December 2018 (UTC)

Protected edit request on 17 December 2018

Why not auto generate date_names.local like this? Ans (talk) 11:42, 17 December 2018 (UTC)

 Not done: please establish a consensus for this alteration before using the {{edit protected}} template. Izno (talk) 12:59, 17 December 2018 (UTC)
I think that this is a good idea but I am opposed to how you have acted to implement the idea. Why did you blow-away all of the changes that are queued for the next update?
Why this construct: '1'..long?
—Trappist the monk (talk) 13:06, 17 December 2018 (UTC)
Since the module documentation said, Editors can experiment in this module's sandbox, so I understood that I can experiment my idea like that. I need to reset sandbox to ensure that my experiment is the only diff, and to see that it work correctly without any other diffs.
--Ans (talk) 15:15, 17 December 2018 (UTC)
That is boilerplate text that exists in every module page whether there is documentation or not. Because the cs1|2 modules are used on so many pages (at present more than 3.8 million) changes to the module suite are collected in the sandboxen and then implemented as a single update. No one is denying that you are allowed to play in the sandbox; all we ask is that you don't undo changes that have been made in answer to other issues addressed here on this talk page.
You have not answered my other question.
—Trappist the monk (talk) 15:31, 17 December 2018 (UTC)

Assistance with Cite Episode template

Since this appears to to be the default talk page for the {{cite episode}} template, I am placing my questions here. I am having trouble figuring out exactly how to use this template in order to cite a television program (which is its intended purpose, yes?). The documentation includes instructions such as date: Date of source being referenced. Does this mean "broadcasting date"? "Air date"? "Date episode was viewed?" "Date episode was written/ published?" Then, what does it mean by "source"? Source of my information? Source of the episode? Source of the date? "Source" is not a parameter! Also: publisher: Name of publisher followed by The publisher is the company that publishes the work being cited. The example then given is the New York Times, which is not a television program. I have no idea how to complete this parameter, or if I should even try. Next, minutes: Time the event occurs in the source; followed by "minutes in". I am not even sure what that means. I think it means, "the time signature, given in hours:minutes:seconds (e.g., "2:32:14" for two hours, 32 minutes, 14 seconds) from the beginning of the episode in question where the referenced information is stated", or something similar. Then, page: The number of a single page in the source that supports the content.— how many "episodes" have pages?? Next: season: Season number, usually for US shows. Should this be provided as "Second" and "First"? "1" and "2"? "Second season"? Will the template automatically add the word "...season" to whatever I DO enter? 2nd? 1st? What if I do not know what my season number is? Will my citation be removed as incomplete? And then there are some more obviously confusing parameters: "title" and "series". The TemplateDate says that I use the title of the program here, and since "title" parameter is usually required (as in {{cite books}}, will not having this produce an error? is this parameter really optional?? (nowhere does the documentation tell me where to indicate the name of the referenced program... unless "program" means "series"?). Next: there is "url", which is supposed to link to a text version of the episode (which would be its... transcript? Script?)... Where do I place a url to the episode where it can be viewed and verified? Then we have "Transcript", which is a parameter for "Transcript of the original source"... This means I should provide my own verbatim transcript of the entire episode?? There is also a separate "Transcript-url" for the url, so what is supposed to go in "transcript"? And "series-link"— should this include double brackets or not? What about "author-link"? "episode-link"?

As you can see, there seems to be LOTS of opportunity for confusion and inconsistency when using this template. Could we get someone to revise the documentation to clarify these kinds of things and include more examples drawn from actual instances of the template in use in actual articles to actual television or radio episodes for comparison? It would also be great if the TemplateData appeared much earlier in the documentation: it is so much easier to understand than all those dozens of descriptions of parameters that seem to have only very limited application for most editors ("mode", "author-mask", "editors", "quote", "zbl", "eissn", "volume", "page", "publication-place", and a bunch more). Thanks! A loose noose (talk) 21:16, 22 December 2018 (UTC)

We will be able to help you better if you provide a few examples of episodes that you would like to cite. Give us the information about the episode using whatever words you are comfortable with, and we can help you translate that information into the right parameters. We may even discover useful improvements to the documentation along the way.
If you go to Template:Cite episode and click on What links here on the left side of the page, you'll see a partial list of pages that use the template (indicated by "transclusion" next to the page title). Click on a few of those pages and then edit each page to see how the template is used on those pages and how it is rendered. That should also help. – Jonesey95 (talk) 22:11, 22 December 2018 (UTC)

When |volume= is a Roman Numeral

I've just been fixing up a couple of citations of a journal which likes to number its volumes as Roman Numerals. This is fine when the result is 4 characters or less, but anything longer than that triggers the condition that removes the bolding from |volume=: this took me aback as I was unaware and I spent some considerable time double-checking that I had entered everything correctly. (FWIW the citations were from volumes 96 and 97 i.e. XCVI and XCVII.) Would it be possible to craft some code which recognises when Roman Numerals are being used and preserve the bolding? TIA HAND —Phil | Talk 15:20, 19 December 2018 (UTC)

I don't see any need to use Roman numerals. I would just write the volume number in Hindu-Arabic numerals, no matter what numerals the publisher used. Jc3s5h (talk) 17:49, 19 December 2018 (UTC)
Heading changed to remove template.
I'm pretty sure that we have considered this option in the past. It is easy enough, I think, to bold the |volume= value if it looks like a number written with roman numerals (only letters from the set [MDCLXVI]). Probably should include a similar rule when the |volume= parameter is written using only the digits in the set [0-9].
—Trappist the monk (talk) 18:08, 19 December 2018 (UTC)
I support this change: citations should stick to the source as closely as possible; searching for a volume that uses Roman numerals requires them to be used in the first place; changing from Roman to Arabic numerals is error-prone. Peter coxhead (talk) 18:16, 19 December 2018 (UTC)
Just systematically bold the volume number, regardless of length, like should have been done ages ago. Headbomb {t · c · p · b} 18:23, 19 December 2018 (UTC)
I have often thought that the conditional bolding of |volume= was bizarre. I checked a few style guides: AIP says volumes should be bold; APA puts volume numbers for journals in italics and for encyclopedias in parentheses with "Vol." (another APA link); Chicago apparently says to use "Vol." followed by the volume number. This is a brief bit of research, but I did not find any that said "bold unless the volume number is longer than n characters or is not just numbers".
What I take from the above quick survey is that we are on our own, and that we do not appear to conform to any standard citation format when it comes to |volume=. I suspect that the current situation is a compromise, since some citations presumably have something like |volume=1940–1946: The World War II Years, and bolding that whole thing is seen as undesirable by some strawman or other. Perhaps we could request a database analysis from some masochistic SQL junkie that would give us a list of the contents of all volume parameters, or a histogram of all volume parameters by length, or something that might help us make a data-driven decision here. – Jonesey95 (talk) 02:12, 20 December 2018 (UTC)
since some citations presumably have something like |volume=1940–1946: The World War II Years Surely that would be better in |title= with what that citation had used as the "title" better placed as the |series=? Umimmak (talk) 02:35, 20 December 2018 (UTC)
All the more reason to make volume appear in boldface. Here are 83 articles with |volume= values that start with "The", and the insource search warns me that the results are incomplete. A database dump would be needed to tell us for sure what sort of madness is out there. If it turns out that all of the really long values should actually be put in |series= or |title=, then bolding will probably make that happen more quickly, so that is all the more reason to applying bolding to |volume= in all circumstances. – Jonesey95 (talk) 03:14, 20 December 2018 (UTC)

As I've advocated, we should match the rendering of |volume= and |number=/|issue= in {{cite journal}} to the rendering in {{cite magazine}}. :^) We really should have a knock out RFC on the topic of what to do with the formatting. --Izno (talk) 15:00, 20 December 2018 (UTC)

More-or-less splitting the difference here:

Cite journal comparison
Wikitext {{cite journal|issue=2|journal=Journal|title=Title|volume=MDCLXVI}}
Live "Title". Journal. MDCLXVI (2).
Sandbox "Title". Journal. MDCLXVI (2).
Cite journal comparison
Wikitext {{cite journal|issue=2|journal=Journal|title=Title|volume=12345}}
Live "Title". Journal. 12345 (2).
Sandbox "Title". Journal. 12345 (2).
Cite journal comparison
Wikitext {{cite journal|issue=2|journal=Journal|title=Title|volume=A}}
Live "Title". Journal. A (2).
Sandbox "Title". Journal. A (2).
Cite journal comparison
Wikitext {{cite journal|issue=2|journal=Journal|title=Title|volume=Civil}}
Live "Title". Journal. Civil (2).
Sandbox "Title". Journal. Civil (2).

|volume= that is wholly digits or wholly uppercase roman numerals is bolded. The last case, is a citation that has |volume= value longer than 4 characters but not wholly uppercase roman numerals (though it is mixed case roman numerals) so not bolded. Additionally, the last example will be added to a (yet-to-be-created) property category Category:CS1: long volume value that may provide data for Editor Jonesey95's musings. Recall that property categories do not emit messages and are subject to the same restrictions as all other categories.

—Trappist the monk (talk) 23:00, 24 December 2018 (UTC)

Thanks. I look forward to perusing the new category. – Jonesey95 (talk) 20:05, 25 December 2018 (UTC)
See also: Help talk:Citation Style 1/Archive 29 § Give a citation bot link when mandatory parameters are missing

Let's revamp the functionality. In {{cite arxiv}}, when you have an incomplete citation (missing mandatory parameters), you have (the rather outdated)

whereas in {{cite journal}}, you have something like

Let's streamline the functionality to look like

  • <normal output> when all mandatory parameters are present
  • <normal output> + <bot message> when one or more mandatory parameters are missing

This would look something like

This should be rather straightforward to code, when something mandatory is missing, append —&nbps;[https://tools.wmflabs.org/citations/process_page.php?edit=toolbar&page={{FULLPAGENAMEE}}&slow=1 Attempt to fix with Citation bot]. This will also streamline {{cite arxiv}} rather than make it the exception.

Headbomb {t · c · p · b} 17:53, 28 August 2018 (UTC)

Looking at Module:Citation/CS1/Configuration, it seems the way to go would be something like a botfixable = true in (for example) 

    accessdate_missing_url = {
        message = '<code class="cs1-code">|access-date=</code> requires <code class="cs1-code">|url=</code>',
        anchor = 'accessdate_missing_url',
        category = 'Pages using citations with accessdate and no URL',
        botfixable = true
        hidden = true
         },

which would append —&nbps;[https://tools.wmflabs.org/citations/process_page.php?edit=toolbar&page={{FULLPAGENAMEE}}&slow=1 Attempt to fix with Citation bot] after (help) Headbomb {t · c · p · b} 01:19, 3 September 2018 (UTC)

@Trappist the monk: this would be a pretty hugely helpful addition. If you can implement the 'botfixable = true' part, I can sync the sandbox to keep which errors are bot-fixable with current bot functionality. Headbomb {t · c · p · b} 01:23, 3 September 2018 (UTC)
Why? If the bot can fix these kinds of errors, there are whole long lists of them at Category:Pages with citations lacking titles and Category:Pages using citations with accessdate and no URL; turn the bot loose on the category pages. Those articles that remain in those categories after the bot runs have completed would not be aided by this proposed change.
—Trappist the monk (talk) 13:43, 3 September 2018 (UTC)
Three reasons. The first is that the bot still makes too many mistakes to be unleashed on 100000+ pages without review. The second is that category runs still require manual activation, and will often crash 100-200 articles in when the bot encounters something like a badly-formed DOI. And third, even if all the bugs were fixed, and continuous runs were possible, it would still take months to clear the categories. There is no drawback to letting editors trigger the bot manually to get ahead of the queue, like we do for {{cite arxiv}}. Headbomb {t · c · p · b} 13:57, 3 September 2018 (UTC)
The crash is fixed. The othet reasons still stand. AManWithNoPlan (talk) 03:44, 22 September 2018 (UTC)
  • I see no reason not to activate this again. (t) Josve05a (c) 01:31, 9 November 2018 (UTC)
  • As long as we show those red messages in the view mode, I think it's useful to add a link which helps people fix them with little effort. If/when they can be fixed automatically, we could as well stop showing them out of the edit preview and just use tracking categories. But we're not there yet. Nemo 12:10, 14 November 2018 (UTC)
    • Maybe we can start with adding the link for some specific errors where the bot is most helpful? Maybe one of those for which the tracking categories know 5k-10k cases. Nemo 16:59, 27 December 2018 (UTC)
      • That would encourage editors to run the bot, which would trigger all its rules and bugs, while shifting (notionally) the responsibility for them and demonstrating consensus for them from the actual bot operators and onto the hapless editor we told to go use the bot. No, that sounds like a spectacularly bad idea. If the bot can reliably fix a problem then let the bot operators get BAG approval in the normal way, and take responsibility for the edits it makes in the normal way, for a run against one of the maintenance categories. These error messages are for informing human editors of a problem; not for advertising someone's pet bot project. --Xover (talk) 20:38, 27 December 2018 (UTC)

Using access-date and archive-date

Is there any benefit to using both archive-date and access-date when there is an archived url? I have been told in the past to remove the "access-date" field when adding a link to an archived version, which makes logical sense to me, but another editor recently restored all the access-date text. It seems like unnecessary cluttering of the references, but I would like to know if this has been decided already?  Mr.choppers | ✎  01:17, 13 November 2018 (UTC)

I provide one or the other, not both, as indeed it is superfluous (given that your archive page reflects the web page as it stood on the access date--not always or necessarily the case for web pages which change frequently--but in that case, you probably wouldn't want the archive page). --Izno (talk) 02:56, 13 November 2018 (UTC)
What is the rationale for including both access and archive dates. It makes citations hard to read and messy. If an archive only exists for a certain date, the access-date is useless. If the archive matches the access-date, it is useless. If the archive verifies the cited fact, the access-date is useless. -- GreenC 04:12, 13 November 2018 (UTC)
Should the template even allow both dates to be displayed? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:14, 3 December 2018 (UTC)
With dead links in citations it is a quite common situation that an archive is added long after the original link has gone dead in order to rescue a reference. In these cases, an existing access-date cannot be "updated" (and shouldn't, because it might even help to find a better archive or alternative link in the future). I think, if both, access-date and archive-date happen to specify the same date, archive-date could be suppressed from display inside the template, but the parameter should not be removed. Otherwise they should both be displayed, as they serve different purposes.
--Matthiaspaul (talk) 22:18, 31 December 2018 (UTC)

Facsimile editions?

Does anyone know what to do when there is a facsimile reprint-edition and the original edition of the book *and* both are being cited in a single "Cite book" reference? For instance, I have come across a situation where I am trying to correct a referencing situation where another editor cited a 1974 reprint of a book originally published in 1902, but the pages vary on each version...I want to cite both editions in the same cite if I can... Thanks. Shearonink (talk) 04:23, 2 January 2019 (UTC)

Per WP:SAYWHEREYOUREADIT cite the version where you read it. The citations written by a previous editor could be left as-is, or if necessary, correct any errors in how the citation is written. Since that is the custom both within Wikipedia and elsewhere, readers will be confused if you try to combine two printings with different page numbering in the same citation. Jc3s5h (talk) 04:33, 2 January 2019 (UTC)
Per OKIWILLHEREYOUGO following is the mangled/error-riddled cite etc. It cannot be left as is so I'm going to fix it. Somehow.:
The article is Battle of Frenchtown, the ref in question is Ref #22. Here is the present code:
<ref>Alexander C. Casselman, ed., ''Richardson's War of 1812'', Vol. 1 (Toronto: Historical Publishing Co.) {{p. 132|date=1902}} facsimile edition by Coles Publishing Co., Toronto, {{p. 164|date=1974}}; Sandy Antal, ''A Wampum Denied, Proctor's War of 1812'' (Ottawa: Carleton University Press) {{p. 164|date=1997}}</ref>
which renders as
Alexander C. Casselman, ed., Richardson's War of 1812, Vol. 1 (Toronto: Historical Publishing Co.) Template P. 132 facsimile edition by Coles Publishing Co., Toronto, Template:P. 164; Sandy Antal, A Wampum Denied, Proctor's War of 1812 (Ottawa: Carleton University Press) Template:P. 164
So. My questions remains...How best to proceed? Is there a way to put both the original edition and the reprint/facsimile edition of a book in a cite? They're the same...yet different-ish. Thanks, Shearonink (talk) 14:25, 2 January 2019 (UTC)
@Shearonink: These are two entirely separate citations: one to a book published in 1902 (the original) and one published in 1974 (the facsimile). They are both editions of the same work, and may contain essentially the same text, but they are different citations: treat them as if they are completely separate books and you probably won't go wrong in practice. Start by including both of them as separate citations, depending on in which edition you found the information that the citation supports. Then, if you like, you can go find all the citations to the edition that you do not have, verify the information in the edition you do have, and then replace the citation with a new one to the edition you have. The end result is that only one of these two editions will be cited in the article. If my quick peek is correct, the only cite to this work is for a couple of numbers in the infobox: in which case you can check those numbers in the edition you have at the page number provided in the existing citation, and then simply delete the information for the other edition.
There is no (reasonable) way to cite both these editions in a single CS1-based citation template, and, as you've found, even doing so in plain text in a ref tag just ends up creating problems for other editors down the line. But on the other hand, it's not really a big issue for a single article to cite two different editions of the same work. It's a bit annoying for readers who have to track down both editions instead of one, but there's nothing really to say you can't choose to do that.
Personally, I would probably re-cite all instances to the original, as that is in the public domain and is easily accessible online (e.g. at Internet Archive). Something like this:
  • Casselman, Alexander C. (ed.). Richardson's War of 1812. Vol. 1. Toronto: Historical Publishing. p. 132.
And then delete the "facsimile edition by Coles Publishing Co., Toronto, P. 164" bit. The template invocation (curly brackets) around the page numbers is clearly by someone that's confused and can be safely removed (should be removed) completely independently of the main issue in this thread. --Xover (talk) 15:39, 2 January 2019 (UTC)
Yeah, figured there probably wasn't a real WP-way to use both. Nice to have the confirmation (and thanks for that link to the Internet Archive version). Cheers, Shearonink (talk) 18:44, 2 January 2019 (UTC)
Xover has already described one way to deal with such situations, but IMHO there are situations where mentioning both editions, the original one as well as the facsimilie edition is beneficial to readers, for example, when the historical original edition is very rare and difficult to obtain and the facsimilie edition is easily available, has extra data attached like ISBNs etc., is frequently cited in other sources, or is of particularly high reproduction quality. In such cases, both could be listed either as two adjacent but separate references or as two citation templates combined into one <ref></ref> block with some intermediate text. --Matthiaspaul (talk) 19:26, 2 January 2019 (UTC)

Total number of pages

In the description of the template "Cite book" for the parameter "pages" it is written: "do not use to indicate the total number of pages in the source". But how to correctly specify the total number of pages? I want to use this template in the "Sources" indicating the total number of pages, and then in the text to use refs on it with "sfn" template.--Nicoljaus (talk) 08:56, 28 December 2018 (UTC)

There is no need to specify the total number of pages in a source, even when you are listing it in a sources section and using sfn or the like. It doesn't matter whether a reference is 100 pages long or 300 pages long.Nigel Ish (talk) 09:33, 28 December 2018 (UTC)
I disagree. The total number of pages is always indicated in bibliographic descriptions. For example, it helps to navigate in different editions of the book, including various e-books.--Nicoljaus (talk) 09:49, 28 December 2018 (UTC)
Perhaps {{cite book}} is not the template for you. cs1|2 does not support total pages; does not support physical descriptions, viz. (cloth : alk. paper); does not support retail price: USD35.00; does not support / and — separator characters. cs1|2 is not ISBD.
You can always add the total pages info after the template's closing }}.
—Trappist the monk (talk) 11:59, 28 December 2018 (UTC)
Price and physical condition is really not needed, but information about the total number of pages sometimes helped me out. However, thanks for the advice.--Nicoljaus (talk) 12:10, 28 December 2018 (UTC)
Total number of pages is irrelevant, and should not be mentionned. Headbomb {t · c · p · b} 14:39, 28 December 2018 (UTC)
"For example, it helps to navigate in different editions of the book, including various e-books."--Nicoljaus (talk) 15:24, 28 December 2018 (UTC)
It doesn't. Knowing the 35th edition has a total of 443 pages, and that the 32nd edition has 473 pages tells me nothing useful. Headbomb {t · c · p · b} 17:47, 28 December 2018 (UTC)
Have you heard about percentages, proportions, and so on?--Nicoljaus (talk) 19:14, 28 December 2018 (UTC)
Hm, different people have different backgrounds, experiences and uses for our citation templates.
The need for a parameter to specify the total number of pages has been discussed many times over the years. It is also implemented in citation templates in a number of other language editions of Wikipedia. While it is certainly not needed in every citation, there are uses and there is obviously a demand for it.
Personally, I find information about the total number of pages potentially useful in various ways: In articles about authors and publications, they are useful information in itself when multiple editions of a work are listed for comparison. This may help readers to decide, which edition to locate, or if an older edition in their possession should possibly be replaced by a newer version. In normal citations, the information may be useful to decide if the work is substantial enough to be worth looking into it at all, or, if it is worth to order the source as a whole or only the cited pages from an archive. There are also older / incomplete citations where knowledge of the number of pages helps to distinguish between editions. In cases, where the total number of pages distinguishes between the pages of the front, body and back matter, this may also give extra clues how to interpret the cited page numbers, thereby helping to reliably source particular statements in a larger or complex work. Finally, having a parameter for the total number of pages as well as for the cited page(s) will help editors to provide reference information more reliably (right now, many editors abuse the existing page(s)= parameter(s) to specify the total number of pages). This misuse will be reduced, if they have a separate parameter for the total number of pages.
It is possible to add the total number of pages in a comment following the citation when needed, but it would be more convenient to have a well-defined place inside the citation template itself, so that it becomes easier maintainable, to streamline the format being used, and also to make it machine-readable.
--Matthiaspaul (talk) 22:29, 1 January 2019 (UTC)
Thank you very much for the well justified opinion.--Nicoljaus (talk) 21:37, 2 January 2019 (UTC)
Unless you're including PDF in "e-book" then the number of pages is going to be thoroughly fluid according to whatever you're reading it on, what font you are using at what size. I fail to understand how the number of pages can possibly be more helpful than other parameters—like date or edition—to distinguish the source for a citation/reference which is what this template is used for. Please educate me? TIA HAND —Phil | Talk 17:28, 28 December 2018 (UTC)
Not only PDF, but also other variants, in which the text of a paper book after recognition is reformatted. At the same time, the paper book had, for example, 200 pages, the 50th page was indicated in the ref. If I would find (for example) only the electronic version, in which there are 400 pages, and then look at the 50th page, and on this page I will not find anything confirming the text of the Wikipedia article. But if I know that this is not just "50th page", but 50th out of 200, then I will look at the e-book of 400 pages in the 100th-page area and it will be much easier for me to figure it out.--Nicoljaus (talk) 19:11, 28 December 2018 (UTC)
It is of no use even for this role when the number of pages of an e-book will vary depending on the individual reader and its settings (such as screen size and text size), not on the edition. This would be only useful if you were writing citations for yourself.Nigel Ish (talk) 23:30, 31 December 2018 (UTC)
Have you heard of percentages, proportions, and so on? "Сitation for myself" does not need the total number of pages, because the values in the fields "page" and "pages" will be put down exactly the same way as in the edition I own. But this is necessary for people who may find another edition with a different total number of pages. Look at the above, I think the example with editions of 200 and 400 pages is quite simple and you can understand what the problem is.--Nicoljaus (talk) 21:34, 2 January 2019 (UTC)

url-access not working?

I've added a few |url-access=subscription parameters to {{cite news}} references in the George Shaw Wheeler article, and the icon indicating subscription access is not appearing in the reference. The parameters seem to work for {{cite web}} in the same article. Has the url-access parameter been disabled for this template? Was it inadvertently broken? -- Mikeblas (talk) 14:02, 26 December 2018 (UTC)

It's the PDF icon interfering with the access lock icon.
Whether that's a bug or intended behaviour I'm not certain of. --Xover (talk) 14:14, 26 December 2018 (UTC)
I don't know if this has never worked or has stopped working because of some change in the order of css application. Only one icon can occupy the space assigned for the external link icon: pdf or access. We must determine which of those is the one that wins. If we decide that the access icon should win then we can do this: 
.cs1-lock-subscription a {
	background: url(//upload.wikimedia.org/wikipedia/commons/thumb/a/aa/Lock-red-alt-2.svg/9px-Lock-red-alt-2.svg.png) no-repeat !important;
	background-position: right .1em center !important;
}
which will override the pdf icon with the access lock. I am not a css expert so there may be a better solution. Izno?
—Trappist the monk (talk) 14:40, 26 December 2018 (UTC)
I would avoid the use of !important by increasing the specificity of the selector. It's possible that the specificity of the PDF icon was increased itself or !important set on that; we'd have to look into the CSS stack to see what caused the issue. --Izno (talk) 15:05, 26 December 2018 (UTC)
That said, the specificity on the styling is pretty high: div#mw_content a[href*=".PDF?"].external with 1 ID, 2 (pseudo) classes/attributes, and 2 (pseudo) elements. We maybe should see about changing mediawiki:common.css which has the offending rule. Removing the div#content from the rule would reduce the specificity to 2 classes and 1 element. The specificity on the other is .mw-parser-output .cs1-lock-subscription a which is 2 classes and 1 element, so that would override the common.css declaration (as it is loaded later). --Izno (talk) 15:16, 26 December 2018 (UTC)
As for when it worked/when it stopped working, it would have stopped working when we switched to TemplateStyles as inline declarations always take precedence regardless of any stylesheets loaded prior (including the user agent's, which is why TemplateStyles is preferable). --Izno (talk) 15:18, 26 December 2018 (UTC)
On an aside, there's a comment by Brion V about the ease of working with these icons. FWIW. --Izno (talk) 15:20, 26 December 2018 (UTC)
I have made an edit request at Mediawiki talk:common.css#PDF rules (pt 1) with my findings. As I said there, the rules here probably need to have a selector added, e.g. .citation. I haven't worked on that problem yet to verify if that's the exact solution. --Izno (talk) 20:52, 29 December 2018 (UTC)
The edit request went through and I have made the appropriate edits to the sandbox modules (catching a missing patch note on the way). You will need to verify the change on a page which has no other citations using {{cite news/new}}. --Izno (talk) 14:18, 5 January 2019 (UTC)

possible to allow date={{date}} template for date parameters?

It would be nice if I could use the {{date}} template within the date type of fields (access-date, archive-date, ...). Currently, setting date = {{date|2019-02-03|YMD}} results in an error.

Is this possible?

JamesThomasMoon1979 08:29, 3 January 2019 (UTC)

It isn't the use of the template that gives the error but the resulting format that is the error. YMD (2019 February 3) is not a format allowed by MOS:DATES so is not allowed by cs1|2. Allowed date formats using {{date}} work:
{{cite book |title=Title |date = {{date|2019-02-03|DMY}}}}
Title. 3 February 2019.
—Trappist the monk (talk) 09:40, 3 January 2019 (UTC)
It may be easier to use CS1's |df= parameter, depending on what you are trying to achieve. – Jonesey95 (talk) 13:13, 3 January 2019 (UTC)
Please never support that, and maybe throw an error when that is used. Headbomb {t · c · p · b} 13:39, 3 January 2019 (UTC)
Too late. |df= has been supported since January 2016.
—Trappist the monk (talk) 13:42, 3 January 2019 (UTC)
Headbomb, what is your antecedent for the word "that"? There are a few different things discussed above. – Jonesey95 (talk) 13:44, 3 January 2019 (UTC)
I was referring to |date={{date}}. Headbomb {t · c · p · b} 13:54, 3 January 2019 (UTC)
Not possible to detect the use of {{date}} because that template is processed before the cs1|2 template; the module only sees the result of the {{date}} transclusion (a date string).
—Trappist the monk (talk) 15:18, 3 January 2019 (UTC)

@Jtmoon: according to Template talk:Date#Shouldn't use 26 November 2024 in articles. Easy cleanup using safesubst: and Template:Date/doc#Description the Date template should only be used internally in templates, not directly in articles. If you have been using it in articles please go back and change the articles to avoid the use of the Date template. Jc3s5h (talk) 18:03, 3 January 2019 (UTC)

Oh dear. --Izno (talk) 18:20, 3 January 2019 (UTC)
It doesn't say why it should only be used in templates, or even why it should be used in templates. Started a discussion there, at least the reasons should be documented. -- GreenC 18:25, 3 January 2019 (UTC)

Wow, thanks for the timely replies @Trappist the monk:, @Jonesey95:, @Headbomb:, @GreenC:, @Izno:, @Jc3s5h:.
When I wrote, " ... results in an error ", this was user error as Trappist the monk replied (｡-_-｡).
Jc3s5h, to clarify, I'm using date={{date|2018-01-04}} (a specific date), like here.
--JamesThomasMoon1979 11:20, 4 January 2019 (UTC)

I would definitely reconsider using this template at all, except for special applications. Plain text is less complexity and always preferred. The template can make things difficult for bots and tools to parse, the result is they will ignore citations containing it thus won't get needed maintenance work done. -- GreenC 18:53, 5 January 2019 (UTC)

Removing format=pdf when the URL ends in ".pdf"

Is there any reason not to remove |format=PDF when the URL is evidently ending in .pdf -- the template is able to detect it and add the PDF icon, |format=PDF is redundant. Or is it used for other purposes also? -- GreenC 18:48, 5 January 2019 (UTC)

The URL is opaque and ending in ".pdf" (or anything else) has no defined meaning. What determines the type of file is the HTTP Content-Type header in the response message. |format=pdf is an explicit labelling of content type. Thus, inferring file type by a heuristic inspection of the opaque URL and relying on the explicit labelling in |format= are not equivalent and replacing explicit labelling with the non-standards-compliant heuristic method would be both incorrect and a worse solution. --Xover (talk) 09:09, 6 January 2019 (UTC)
In plain English please? Because if you link to a PDF file, and the template automatically determined it to be a PDF file and automatically appends |format=PDF, then there's no reason for anyone to manually append |format=PDF in those cases. Headbomb {t · c · p · b} 14:48, 6 January 2019 (UTC)
Which part did you not understand? And the templates do not add any parameters by themselves, so |format=PDF is always added by an editor. --Xover (talk) 15:19, 6 January 2019 (UTC)
Nearly all of your post. As for |format=PDF, yes that's added by editors (and possibly bot/scripts), that's why I'd want citation bot to remove |format=PDF when they are automatically added, because it's just pointless clutter to have. Headbomb {t · c · p · b} 15:30, 6 January 2019 (UTC)
Well, if you do not understand the basics of how this works, would it not be a more prudent approach to attempt to gain that understanding? Because you've just written that you want Citation Bot to remove parameters added by human editors because they were added by human editors. Nothing that I am aware of automatically adds |format=PDF, and if anything (like Citation Bot) erroneously adds it automatically then the correct course of action is to prevent whatever that automated tool is from doing that in the future. It's possible that VE or Reftoolbar or something tries to be helpful by adding it based on some heuristic, but then it is also always saved by a human editor afterwards. In other words, the set you are describing is nil. --Xover (talk) 16:03, 6 January 2019 (UTC)
"Well, if you do not understand the basics of how this works, would it not be a more prudent approach to attempt to gain that understanding?" What exactly do you think this whole discussion is about, if not an attempt to gain that understanding? And the set isn't nil, because the redundant use of |format=PDF is widespread. Headbomb {t · c · p · b} 16:14, 6 January 2019 (UTC)
Well, I believe GreenC was looking for feedback and discussion on the merits of an explicit |format=PDF for citations which contain the string ".pdf" in the URL. However, based on your posts in this thread it appears that you are seeking justification for pursuing a course of action that you have already decided you want to pursue; because you're mostly just making assertions and not asking questions. Calling something which you do not understand "redundant" "pointless clutter" does not seem particularly apt to give the impression of someone who is seeking better understanding. --Xover (talk) 16:47, 6 January 2019 (UTC)
Is a (PDF) or a (PDF) better is the question. AManWithNoPlan (talk) 17:10, 6 January 2019 (UTC)
Clearly the former, as far as the reader/editor is concerned. The question is, is there a technical reason of some kind to not do this. Headbomb {t · c · p · b} 17:19, 6 January 2019 (UTC)
A reasonable question, but, as I explained in my reply to GreenC above, the syntax for URLs do not assign any particular meaning to what some are used to thinking of as a "filename extension" (which is an OS convention originating on Windows): that part of an URL is just an opaque text string. An URL ending in ".pdf" can (and not infrequently does) return something other than a PDF. The way to find out what's returned is to do a GET or HEAD request on the URL and look at the MIME media type returned in the HTTP Content-Type header of the response. Conversely, |format=PDF in a citation template reflects an editor's explicit intent to indicate that the resource referenced by the associated URL is a PDF file. That is, it reflects human judgement. Their intent may well be misguided, of course, and their judgement flawed, but there is no reasonable way to determine that absent manual inspection (i.e. another human's judgement). In other words, the two methods to determine file type are not equivalent in function, implementation, or semantics (or, put anoter way, they're only "redundant" with eachother if you squint just right): and the one that is amenable to automated processing is both the worse (inaccurate, error prone) and not standards compliant. --Xover (talk) 17:39, 6 January 2019 (UTC)
(edit conflict) For clarity. When cs1|2 sees this:
{{cite book |title=Title |url=//example.com/some_doc.pdf}}
it renders this:
Title (PDF).
The pdf icon is added by MediaWiki:Common.css (search for pdf). That icon is a background image. That type of image does not allow for alt text so, for accessibility reasons, cs1|2 adds the (PDF) annotation. It does this by inspecting the value assigned to |url= using rules similar to those used by MediaWiki:Common.css.
At en.wiki it can be argued that |format=PDF is redundant when the file type extension of the value assigned to |url= indicates a PDF document. Other wikis copy citations from en.wiki and these other wikis may not have current version of the cs1|2 modules (may still be using some version of {{citation/core}}). Those wikis, benefit from the existence of our 'redundant' |format=PDF and we are not harmed by its presence.
—Trappist the monk (talk) 17:29, 6 January 2019 (UTC)
More generally, I wonder if it is truly necessary to keep this mostly-legacy special-cased behavior around. I would actually move to remove it. --Izno (talk) 18:04, 6 January 2019 (UTC)

Language parameter

Not sure if I should be asking here or at MOS but I've noticed recently that a lot of citations are now including |language=en.

Is this some change in guidance/policy or it is perhaps the result of people using a particular gadget that adds the thing? I can understand the need to specify the language if it is not in English but this is the English language Wikipedia and it seems to me just to be more clutter in the edit window to announce what should be the expectation anyway. - Sitush (talk) 15:50, 8 January 2019 (UTC)

Citoid includes |language=en. The citation module obviously does not render anything in the final output. It is useful for translators to know what the language is. --Izno (talk) 15:56, 8 January 2019 (UTC)
Similarly, when the cs1|2 modules are used on other-language-wikis, when |language= is 'their' language, it is not rendered there. The exception is (for all wikis) when the local language is one of several languages listed in |language=.
—Trappist the monk (talk) 16:01, 8 January 2019 (UTC)
Ah, I'd never looked at Citoid before. I still think it is clutter. I can't imagine we have that many translators, and I'm pretty sure most of them would recognise English when they saw it. Especially since they would be translating from the en-WP article anyway. - Sitush (talk) 16:16, 8 January 2019 (UTC)
It isn't for the translators but for the readers of en.wiki articles that have been translated for use on other wikis. WP:MED has a rather robust translation effort. |language=en at other-language-wikis tell readers of those wikis that this particular source is written in English so that is as useful to them as citations here with |language=fr.
—Trappist the monk (talk) 16:33, 8 January 2019 (UTC)
Well, if an en-WP article has been translated for use on another wiki then it is surely a part of the translator's role to modify cites as required, just as they would also have to modify the article to comply with that wiki's policies and guidelines (different MOS, different RS etc). It still doesn't make it necessary to fill in the parameter with "en" here.
I am not disputing that the parameter has uses, I am querying why it should be filled by default with the native language of whichever wiki it is being used on. It seems that may be an issue more to do with the tools than anything else, ie Citoid, the RefToolbar and whatever else may do so. Oddly, and merely from casual experience rather than empiric study, it seems likely to me that the parameter is not being filled automatically with, say, |language=hi or |language=ta on this wiki even though that certainly would fit with the rationale you and others have explained; perhaps that is just because I haven't happened acrossl the right articles yet, although I look at hundreds most days and have not long since cut my watchlist down to ca. 4,000. - Sitush (talk) 19:36, 8 January 2019 (UTC)
What language it is filled in with depends on the URL being accessed and whether the publisher of that URL has made the metadata available to indicate the language of the work. I regularly see |language=de and |language=fr (and occasionally |language=ja) filled in with my uses of Citoid.
I doubt anyone here would be bothered if you removed |language=en from articles you care about; just know that it does have its uses and so you would probably have some resistance if you wanted to bot-remove them. In some articles, there are multiple-language works which will include English, which displays like Book (in French, German, and English), which does include English in the output so-as not to mislead the reader. --Izno (talk) 19:45, 8 January 2019 (UTC)
Ah, its generated from metadata - that would explain the scarcity of Indic ones, thanks. I've no intention of ever running a bot and don't even care for AWB, so no worries there, and I almost always do the cite templates by hand, the exception being the occasional use of the reflinks tool when I find an article with a load of barelinks and can't be bothered running through them all. I'm still not really seeing why inclusion of the parameter for native languages should be by default with Citoid and RefToolbar but then I don't understand your last sentence either, sorry, and suspect the answer lies in that. - Sitush (talk) 20:08, 8 January 2019 (UTC)
It also happens automatically if Wikipedia:RefToolbar automatically fills in the fields from a URL, and people might just not notice or care to remove it. Umimmak (talk) 18:21, 8 January 2019 (UTC)
I can imagine this being useful if the title of the work cited is not in English, but the work is; a book called "La Vie en Rose", for instance. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:39, 8 January 2019 (UTC)
Perhaps, but again that would be a rare occurrence and could be dealt with as an exception to the rule. - Sitush (talk) 19:36, 8 January 2019 (UTC)

update to the live cs1/2 module weekend of 19–20 January 2019

I intend to update the live modules over the weekend of 19–20 January 2019

changes to Module:Citation/CS1:

  • add .cs1-maint, moved styling to styles.css; see discussion
    maint message presentation now part of cfr.presentation{};
    fixed extraneous trailing space character
  • i18n of language name separation; see discussion
  • recognize n and mdash entities in page/issue ranges; see discussion
  • remove support for 'interviewers' parameter; see discussion
  • expand support for tagged language codes; see discussion
  • get_iso639_code() bug fix; see discussion
  • bold all of |volume= when value is all digits or all uc roman numerals; see discussion
  • support for cite wikisource; see discussion

changes to Module:Citation/CS1/Configuration:

  • add .cs1-maint, moved styling to styles.css
  • remove support for 'interviewers' parameter;
  • add lang code for Sinhalese
  • expand support for tagged language codes;
  • remove cnr/montenegrin;
  • add lang codes for Hindi, Kazakh, Khmer, Nepali, Tamil
  • support for cite wikisource;

changes to Module:Citation/CS1/Whitelist:

  • remove support for 'interviewers' parameter;

changes to Module:Citation/CS1/Date validation:

  • i18n; add support for YYYY mmmmm DD date format (ml.wiki); see discussion

changes to Module:Citation/CS1/Identifiers:

  • i18n: support non-Latin script digits in |isbn=; <bdi>...</bdi> around ISBN to prevent reversal at right-to-left wikis; see discussion;

changes to Module:Citation/CS1/styles.css

  • add .cs1-maint, move styling to styles.css
  • increase specificity of <q> styling for consistency; see discussion
  • increase specificity lock styles; see discussion
  • refactor to group styling by function

—Trappist the monk (talk) 11:48, 12 January 2019 (UTC)

Updating them in September 2018? Have you invented time travel lately? --Izno (talk) 14:42, 12 January 2019 (UTC)
No, I've been working on a secret you-know-what-I-want version of copy/pasta control (Ctrl+v+y+k+n+w+i+w) which, as you can see, is not yet production-ready.
—Trappist the monk (talk) 15:13, 12 January 2019 (UTC)

Vertical version of commonly used parameters for Cite book?

I would like Template:Cite book to include a vertical version of commonly used parameters. --77.173.90.33 (talk) 17:21, 16 January 2019 (UTC)

The documentation is not protected. You are welcome to edit it. – Jonesey95 (talk) 18:02, 16 January 2019 (UTC)
Alrighty; done. --77.173.90.33 (talk) 18:14, 16 January 2019 (UTC)

Cite episode and author

The documentation says this for |author=: Title of existing Wikipedia article about the author; can suffix with a numeral to add additional authors - what exactly should be added here? The directer? Teleplays writers? Story writers? Showrunners? Seems this (and |first= and |last=) should either be removed for this template or have a different name. --Gonnym (talk) 08:43, 22 January 2019 (UTC)

I think you are confused. That definition comes from Template:Cite episode#TemplateData for |author-link=.
—Trappist the monk (talk) 09:48, 22 January 2019 (UTC)
Yes, you are correct, but the issue is still the same as it talks about the author. Also, one parameter above: |author-first= (or one of the other aliases) that says: Given or first name, middle names, or initials of the author; don't wikilink, use 'authorlink'; can suffix with a numeral to add additional authors. --Gonnym (talk) 11:21, 22 January 2019 (UTC)
Now I'm not sure what you are asking. The common element of the texts you quoted is: can suffix with a numeral to add additional authors so is your question about that?
Author parameters are about the author(s) of the source so if Abraham Lincoln is the author of the source and the template uses |last=Lincoln and |first=Abraham, set |author-link=Abraham Lincoln so that the rendered citation gives:
{{cite book |last=Lincoln |first=Abraham |author-link=Abraham Lincoln |title=Title}}
Lincoln, Abraham. Title.
—Trappist the monk (talk) 12:56, 22 January 2019 (UTC)
I know what a book author is. I was asking how this is relates to a television episode. What value is expected for this parameter - the writers (and if so, which, as there are 3 different types)? the directer? The showrunners for the entire series? Each of those can be an entry for the author and at the same time all 3 are not authors of an episode. So asking again, should this parameter be available in {{Cite episode}} and if so, what value is the correct one and if it is kept, wouldn't a more correct parameter name be advisable as episodes don't have authors? --Gonnym (talk) 13:08, 22 January 2019 (UTC)
Someone had to author the words that the actors speak; someone had to author the stage direction, etc. Name the person or persons (never more than one in a single parameter) who authored whatever it is in the episode that you are citing. What is it that I am not understanding about your question?
—Trappist the monk (talk) 14:45, 22 January 2019 (UTC)
That there is no author for an episode. There is a director, a writer, a screenwriter, a teleplay writer, a showrunner, an executive producer, but no author. As you can see these are very different credits from each other, so sticking them all to author is a bad style at best. --Gonnym (talk) 15:36, 22 January 2019 (UTC)
Is the question that you are really trying to ask: Can we add {{cite episode}}-specific |authorn= aliases:
|director= – once supported for {{cite DVD notes}}; removed long since
|writer=
|screenwriter=
|teleplay-writer=
|showrunner=
|executive-producer=
or is the question: Can we remove support for |authorn= along with its attendant aliases and related parameters from {{cite episode}} because episodes don't have authors? I dispute that last notion; someone or some set of someones must author an episode because fully-formed episodes don't simply appear as if by magic.
—Trappist the monk (talk) 20:03, 22 January 2019 (UTC)
No need to guess what I really was asking, as I plainly said it 3 different types in 3 different ways So asking again, should this parameter be available in {{Cite episode}} and if so, what value is the correct one and if it is kept, wouldn't a more correct parameter name be advisable as episodes don't have authors? The situation now where "author"(or "first"/"last") should be used but not explained in any way what person should be added to it, does not add any value to articles. I personally wouldn't mind seeing it removed, as an author does not exist for an episode, that is, the audio-visual finished product. Unlike a book were it is mostly written by one person with an editor, the episode has many moving parts. An episode script does have an author, but not all scripts have the visual style written in them, which comes from the director (or even Director of Photography). So if you wanted to cite an episode for a reference to something visual or even a sound design, that isn't the writer. That said, if we do continue on keeping it, the parameter should be changed so a consistent use and visual style will show up when used. For example, when I saw it used today, the editor who added the template, added the roles in parenthesis "Marc Guggenheim & Keto Shimizu (writers) & Glenn Winter (director)", which I'll take a wild guess and assume is not how everyone who used it does. Also, to make things a bit more complicated, in the US there is a difference between "Writer A and Writer B" and "Writer A & Writer B" (WGA screenwriting credit system). --Gonnym (talk) 20:39, 22 January 2019 (UTC)
Maybe you did but you seem to be hung-up on author does not exist for an episode in some sort of a strict noun-form definition. I rather see author as a more generic term that can and should be applied as a parameter that names one who has created something that is being cited; |authorn= exists for all cs1|2 templates, it is not likely to go away.
That you find the documentation for {{cite episode}} inadequate is a common condemnation of all cs1|2 template documentation. If you can see how the documentation can be made better, please do so. I don't use the template so I am not qualified, and no, I did not write the template, I just implemented it in Module:Citation/CS1.
Lumping human names with roles in name-holding parameters is not good practice because that extraneous text corrupts the citation's author metadata (yeah, director, producer, whatever, if we had parameters with those names, would all be reduced to author k/v pairs in the citation's metadata). Editors who use |people= write citations that do not include the names of those people in the citation metadata because |people= is an alias of |authors= which, because of its free-form nature and the diversity of human naming constructs, is not included in citation metadata. cs1|2 is not bound by writer's guild rules just as it is not bound by Chicago, APA, or whatever other style guides are out there.
I suggest that you confer with editors in projects that use {{cite episode}} and with them develop a set of |authorn= aliases and the rules for their use and rendering. Give us links to those discussions.
—Trappist the monk (talk) 13:25, 23 January 2019 (UTC)

Registration without url

The templates currently complain when given |accessdate= but no |url=. Shouldn't they do the same when given |registration= but no |url=? —David Eppstein (talk) 08:01, 23 January 2019 (UTC)

Yes. Or better, to deprecate and remove |registration= and |subscription=
—Trappist the monk (talk) 09:02, 23 January 2019 (UTC)
I've done this. "Example". {{cite web}}: Unknown parameter |registration= ignored (|url-access= suggested) (help)
"Example". {{cite web}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)
--Izno (talk) 18:08, 26 January 2019 (UTC)

Common usage section should include archive-url= and archive-date=

Common usage section (should include |archive-url=| and |archive-date=| even though if usage isn't as common as it should be and a lot of pages are NOT saved and protected from Link rot as a result, the way it automatically pulls usage data from all the language wikis and shows the most common is very technically impressive but not the most reasonable thing to do when setting guidelines for usage as it simply encourages people to carry on with the way things are instead of encouraging to do them better (since the way to do a cite is presented as a line for people to copypaste into the wiki, it sets bad habits from the start and doesn't encourage people to make a copy at all).


(separate issue but I don't want to make a new section to encourage skipping over this more important one, is that Help:Citation_Style_1#Titles_and_chapters has no guideline on what to do when the title of a PDF document is on multiple lines, if there's any symbol we should use to indicate a line break since Wikipedia does not support titles with line breaks in between - using a comma isn't always appropriate as in the case of 

Public Health
Assessment
Final Release
Vapor Intrusion and Off-Site Irrigation Well
CONTINENTAL CLEANERS
MIAMI, MIAMI-DADE COUNTY, FLORIDA
EPA FACILITY ID: FLD982130098

becomes Public Health, Assessment, Final Release, Vapor Intrusion and Off-Site Irrigation Well, CONTINENTAL CLEANERS, MIAMI, MIAMI-DADE COUNTY, FLORIDA, EPA FACILITY ID: FLD982130098 (the first case making showing the line break not as important, the second red comma making it clear that using comma to indicate a line break would create serious problems for titles that use commas in their actual title already like the example) --Archive everything do it now (talk) 18:06, 26 January 2019 (UTC)

@Archive everything do it now: there is a bot that already does wonders to prevent link rot. The Internet Archive monitors every edit make to Wikipedia right now, and they automatically archive every link added in those edits. Then IABot monitors pages to see if links cited within have gone dead. If so, it automatically adds the Internet Archive links into the appropriate citations. This doesn't necessarily help with links added before the project began a few years ago, but it does work on edits now. IABot also adds links to WebCite or Archive.is as appropriate if the Internet Archive doesn't have an appropriate archive available. The bot also changes |dead-url= from no to yes if a preemptive archive was added, thus switching the linked title from the original link over to the archive when a link has gone dead and an editor has already supplied an archive link.
Speaking of preemptive archives, if you go the history page for an article, you'll see a "Fix dead links" link near the top. Click that, and you can add archive links for dead links, or preemptively archive all of the links in all of the citations. So in short, there are some great tools that already fighting link rot, one of which is in the background doing things already. Imzadi 1979 → 23:38, 26 January 2019 (UTC)

{Template:Cite conference}: Why italic title for paper presented at a conference?

To oversimplify, we generally use quotation marks for the title of shorter published works (a journal or newspaper or magazine article, a chapter in a book, a song, a poem) and italic for title of longer works (a journal, newspaper, magazine, book, recording album, or anthology of poems). However, {{Template:Cite conference}} (1) uses italic for the title of a paper, which is comparable to a journal article; and (2) uses roman for the collection of papers presented at the conference, which is comparable to a journal or book. Why this inconsistency? Chicago style uses quotation marks for the title of the paper and italic for the published proceedings of the conference.—Finell 03:25, 27 January 2019 (UTC)

It ... doesn't?
  • {{cite conference |last=Smith |first=J. |year=2006 |title=Title of paper |book-title=Proceedings of Foo |volume=40 |pages=24-49 |publisher=Foo Society }} gives
  • Smith, J. (2006). "Title of paper". Proceedings of Foo. Vol. 40. Foo Society. pp. 24–49.
Headbomb {t · c · p · b} 04:50, 27 January 2019 (UTC)
The problem he's running into is {{cite conference |title=Paper Title |conference=Conference Title }}: Paper Title. Conference Title.. |book-title= is not the obvious title for the proceedings, at least in Template:Cite conference#Usage, and the Examples just below indicate the incorrect use, if indeed |book-title= is meant to be used to hold the name of the proceedings.
That said, I believe the intent of the template is to hold the proceedings themselves, not the papers published in the proceedings. You should prefer Template:Cite journal or Template:Cite magazine for those? --Izno (talk) 15:17, 27 January 2019 (UTC)
No. Conference proceedings papers are not journal papers and they are not magazine papers. If you're not willing to use the one-size-fits-all {{citation}} for them, I believe the recommended choice is (completely non-obviously) {{cite encyclopedia}}. But cite conference should be made to work with the natural parameters. —David Eppstein (talk) 22:34, 27 January 2019 (UTC)
Yes. ♦ J. Johnson (JJ) (talk) 23:52, 4 February 2019 (UTC)
We have been here before. That conversation stagnated and never reached conclusion.
—Trappist the monk (talk) 00:30, 5 February 2019 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Help_talk:Citation_Style_1/Archive_50&oldid=1121665797"