Share to: share facebook share twitter share wa share telegram print page

 

Help talk:Citation Style 1/Archive 48

Archive 45Archive 46Archive 47Archive 48Archive 49Archive 50→Archive 55

Permit access-date in absence of a URL

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
(non-admin closure) The result is by consensus Yes, keep the current practice. Plus, the instructions about citing web sources are quite clear: "Access date" is the full date when the content pointed to by URL was last verified to support the text in the article; requires URL. Emphasis on the last sentence.
The objections against the current practice are indisputably well meaning. Supporters of retaining the Access Date in the absence of a URL invoke policies such as WP:AGF and essays such as WP:HIJACK but those are irrelevant: Citation highjacking can be amended easily and quickly by re-adding extant, live references, while the value of information in an article should be weighed on its own, i.e. the Wikipedia user searching for information is not interested in the good faith, assumed or not, of previous editors.
Jonesey95 pointed out that a no-URL access date "shows a diligent reader where to look at archive.org to check a source that may have changed since the access-date." However, an online search is an online search and the date when a web source was last accessed, even if the date accepted is correct (i.e. not a mistake), is not a significant factor in online-source search.
Objections regarding technical difficulties, such as the adjustment of bot functions, can be discounted since bots are here to assist human editors in their work and not to shape the work. The Gnome (talk) 08:00, 29 September 2018 (UTC)

Should use of |access-date= in citations (indicating the last date at which the source was checked as verifying the claims for which it was cited) be treated as an error and removed from citations that do not have a URL?  — SMcCandlish ☏ ¢ 😼  04:36, 28 July 2018 (UTC)

Comments

  • No. Somehow we've lost the |access-date= in {{Cite book}}. This is a terrible idea. At this point, probably the outright majority of book citations (or at least new ones being added) are via Google Books or otherwise have a URL. The |access-date= tells us something important: The date at which someone verified [or indicated they verified] that the source cited is a source for the claim[s] appearing in front of that citation. This is one of the ways we can detect WP:Citation hijacking. Keep in mind also that what is available at Google Books or some other site might change at any time; just because a snippet view with the content needed was visible on 29 March 2007 doesn't mean it is now. If someone goes to verify the claim and can't find it in the online material, they're apt to delete the claim or put {{failed verification}} on it, when it may in fact really be in that book, just not visible right now at that particular |via='s URL. If the access-date is also from 2007 or so, this is an indicator that we may need to check the print source. If the access-date is yesterday, then it's probably sourcing falsification.  — SMcCandlish ☏ ¢ 😼  19:20, 27 July 2018 (UTC)
    John Smith (2003). Title. p. 8. Retrieved 20 February 2011. works for me. Headbomb {t · c · p · b} 19:22, 27 July 2018 (UTC)
    I must be losing my mind. I just had it fail for me within the hour. Will see if I can replicate it.  — SMcCandlish ☏ ¢ 😼  19:58, 27 July 2018 (UTC)
    Ah, it's failing when there is no URL: John Smith (2003). Title. p. 8. {{cite book}}: |access-date= requires |url= (help). This is still arguably undesirable, because the date info tells us when someone looked at this data and confirmed it as sourcing the claim. I guess it's not a fatal problem, since it remains in the wikisource, but I've seen well-meaning but boneheaded gnomes remove it as "inapplicable" and it's tiresome to have to revert them again and again. Maybe the doc should be updated to say to leave the "silent parameter" there as an anti WP:HIJACK tool.  — SMcCandlish ☏ ¢ 😼  20:06, 27 July 2018 (UTC)
    Done [1]. This is a good compromise. Don't actually need the a-dates to be rendered in absence of a URL, but people shouldn't be nuking them either.  — SMcCandlish ☏ ¢ 😼  20:12, 27 July 2018 (UTC)
    if this change is agreed then the tracking category Category:Pages using citations with accessdate and no URL and the section at Help:CS1_errors should be deleted as being of no use and/or contradictory to the change you've just made. Nthep (talk) 20:25, 27 July 2018 (UTC)
    If I am not mistaken it was removed because the archive bot doesn't work for them and gives us dead links if there is an access date.--Moxy (talk) 20:20, 27 July 2018 (UTC)
    So, fix the bot. Agreed that the material at Help:CS1 errors should change. Category:Pages using citations with accessdate and no URL can stay; not all maintenance categories are about errors and indicate a backlog; many of them (e.g. all our redirect classification categories) are useful for other things. This one in particular could be used for periodically re-checking for online versions of things to provide URLs, and can be sifted through for, e.g., erroneous uses of {{cite web}} without the required URL parameter, and so forth and so on.  — SMcCandlish ☏ ¢ 😼  23:10, 27 July 2018 (UTC)
    Alright, so Izno's reverted me here [2] with a claim there's a "general consensus" against the idea. I don't believe this is true at all. I've been involved in most of the previous discussion of this and it's the same handful of bot-oriented people who oppose the idea, and who never respond substantively to the content-editorial concerns. This is a WP:STONEWALL, a WP:FALSECONSENSUS. It's been tiresome for a long time. "The bot won't handle it the way want yet" is a reason to upgrade the bot. The tech tail does not wag the editorial, content verification dog.  — SMcCandlish ☏ ¢ 😼  00:05, 28 July 2018 (UTC)
  • Yes, keep current behavior. Can you explain how having an access-date but no URL for a book source is in any way useful? What information is it supposed to convey to other editors (since it will be invisible to readers)? How is this in any way an anti-hijacking measure? If editors are checking whether a diff hijacked a reference, how will looking at this date help them? Are you expecting people who add an updated claim from the same reference, in a way that looks like it could be hijacking but isn't, to understand your cryptic countermeasure and update the access-date in order to reassure you that they're on the up-and-up? Why do you think they will know or care to do that? —David Eppstein (talk) 00:27, 28 July 2018 (UTC)
    My understanding is that |access-date= exists to show when a web page was verified as supporting a specific claim. Since web pages can change, the access-date shows a diligent reader where to look at archive.org to check a source that may have changed since the access-date.
    Books, journal articles, and other sources that exist in a revision-controlled world (e.g. edition or version numbers are almost always explicitly changed when the document is changed) do not need an access-date, because they (presumably) do not change. – Jonesey95 (talk) 00:35, 28 July 2018 (UTC)
    I agree broadly with these points. --Izno (talk) 00:55, 28 July 2018 (UTC)
  • Accessdates without URL should absolutely be removed. User_talk:CitationCleanerBot/Archive_1#Accessdates outlines why in details, but it largerly mirrors Jonesey/Izno/David Eppstein's points from above. Books are fixed resources, accessdates are completely pointless for them when there is no url (and even with them they are pretty near pointless). Headbomb {t · c · p · b} 01:29, 28 July 2018 (UTC)
The obvious problem with this analysis is that it's our own content that is more likely to change than any URL, very frequently resulting in WP:HIJACK. This is a massive hassle to track down, and is made much easier with an access date: you simply go directly to that date in the page history; on a busy page this can save a tremendous amount of time digging around trying to figure out when a cite was first added. This verifiability boosting effect has nothing to do with URLs. It's weird to me that people aware that the parameter can serve one function seem blind to the fact that it can serve another which is also important. Seems a bit like denying that italic markup can be used for anything but titles of works and "therefore" that its use for genus and species should be banned. Heh.  — SMcCandlish ☏ ¢ 😼  05:26, 28 July 2018 (UTC)
You cannot hijack a non-websource, so again, |access-date= makes no sense when there's no URL. Headbomb {t · c · p · b} 00:31, 30 July 2018 (UTC)
He is referring to the phenomenon where some editor adds new claims in front of an existing footnote so that it looks like the new claim is sourced when it isn't. He wants to abuse access-date to somehow detect this problem. I think this is a mistaken attempt at a solution (because it only works if everyone who adds new claims also knows to adjust the access-dates, and if the people who want to insert claims without taking the effort to source them don't also learn to adjust the access-dates to make their changes stick). But it's not a non-problem. —David Eppstein (talk) 01:43, 30 July 2018 (UTC)
  • Keep current behavior. I don't know anything about a bot and certainly would not argue that a bot shouldn't be fixed, were that the objection. :) I am just asserting "'accessdate requires URL' because the accessdate is for the URL" has been the use of the parameter since 2009 in Citation/core. The warning was added in 2013 during conversion to Lua (and categorization somewhere later). --Izno (talk) 00:43, 28 July 2018 (UTC)
  • Opening this as an RfC since I'm being revert warred on dispute tags trying to draw additional eyes and minds to the discussion.  — SMcCandlish ☏ ¢ 😼  04:36, 28 July 2018 (UTC)
    Since you retroactively turned our conversation into an RfC (not generally a good idea), I've retroactively edited my comment to add a boldfaced word at the start that makes clear my position. —David Eppstein (talk) 04:49, 28 July 2018 (UTC)
    I did as well. And RfC stuff happens this way all the time. No one cares, as long as the question is clear. :-)  — SMcCandlish ☏ ¢ 😼  05:21, 28 July 2018 (UTC)
    @SMcCandlish: But the question isn't clear (see David Eppstein's mis-clarification in edit history), and it too narrowly focusses on your Google Books use case to the detriment of issues such as that brought up by Masem. What you're really asking about is the semantics of |access-date= (which is a wide issue worth debating properly), but you've phrased it as a question about a simple technical issue. The issue isn't |url= or no URL, it's ephemereal source or not. --Xover (talk) 06:17, 28 July 2018 (UTC)
  • Yes—continue to treat the access date as an error for offline sources. Access dates in citations exist to give a known date for a source published without an explicit date, or to confirm a date when a source of an ephemeral nature was accessed. Fixed sources, like printed materials, do not need such a thing. Imzadi 1979 → 05:35, 28 July 2018 (UTC)
  • Oppose I am sure that there are electronic resources that you cannot provide a direct URL to the resource (or enough of one to meet WP:V) which do get updated over time, so the access date is important for those resources. There's likely only a handful of such cases, but they still exist. --Masem (t) 05:42, 28 July 2018 (UTC)
  • Keep present behaviour – the access date relates to the material located at the URL, and is inappropriate for sources with no URL – it's not to verify when the editor checked, but to indicate which version of a possibly changing web page was accessed. Peter coxhead (talk) 06:34, 28 July 2018 (UTC)
  • Yes, keep present behavior. The RFC question asserts that this date represents "the last date at which the source was checked as verifying the claims". However, I don't think that is entirely true. It seems to me that – in actual practice, and not withstanding the OP's past efforts to change it – it represents the last recorded date at which the URL was known to be working (i.e., both not a dead link and also still leading to the cited source). There is no point in recording a "URL still working as of" date when there is no URL. Also, NE2 seems to have originated this idea and may want to comment on whether this idea seemed descriptive of actual practice, or if it might have been a bit of hopeful thinking. I don't think that I've ever seen anyone treat this date as meaning that the source had been checked; if so, then we should never put {{verify source}} after any citation that contains an access date (because that allegedly means that some actually already did verify every single one of those citations with access-dates, right? Well, I'd say no, myself, but I'd also change the help docs to be clearer that it doesn't mean that). WhatamIdoing (talk) 06:49, 28 July 2018 (UTC)
    • A slightly more specific response than yes/no:
      • If a URL is not present, the access-date should not display. It should not necessarily display an error when |url= is empty, as the relevant "URL" might be one of the identifiers. I don't really care whether bots or AWB scripts keep or remove them.
      • If a real date is present, I think that the access-date generally does not need to display. I don't care what date you looked up something on Google Books; I care when the book was published. However, it's possible that the ideal varies by source type: display for cite web and cite news, but not for cite book and cite journal.
      • Nobody should treat access-date as meaning that the cited source and the current wikitext claim were checked for being the related. The meaning of access-date is that you could access the cited source at that time. It is not a verified-on-date.
You should especially not treat access-date as meaning verified-on-date when the URL leads to identifier records such as worldcat.org or paywalled sources (e.g., most scientific journal articles). Those URLs rarely verify the content directly, even though they are valuable links. WhatamIdoing (talk) 16:06, 28 July 2018 (UTC)
Well, the access-date parameter indicates the date that the source was last checked, so in a way it gives you both the date that the URL was last live, and the date when the resource at that URL was consulted for the article. Otherwise, what's the point of a parameter that says a given URL was live when the content at that URL isn't relevant anymore? – Uanfala (talk) 16:17, 28 July 2018 (UTC)
No, it doesn't indicate the date that the source was "last checked". It indicates "a day" (perhaps only rarely "the last day", since these dates are not usually updated) when the source was "accessed" and determined to be present at that URL. There is a significant difference between "The citation says that this is the 'About Us' page at example.com, and I found that it was indeed the 'About Us' page for that website" (which is what that date means) and "I went to this page, and not only is this the URL to the 'About Us' page still working, I scrolled through the whole 'About Us' page just to make sure that it still says that Alice Expert is their Chief Expertise Officer".
As for why that's relevant, WP:Link rot is a problem with sources that aren't web-only and endlessly mutable (such as 'About Us' pages). It's also a problem with URIs to pages whose content will reliably be preserved somewhere, such as newspaper articles and government records. (Remember all the problems we had with editors adding links to news.yahoo.com links, all of which expired after a couple of weeks?) WhatamIdoing (talk) 05:30, 1 August 2018 (UTC)
Well, if that were the way this parameter is most commonly used on wikipedia, then it would be either misleading or at best entirely useless, and should be deprecated altogether. But that's not how editors normally use it and it's not how it is supposed to be used, see for example how documention of Template:Cite_ web#URL: defines access-date: "Full date when the content pointed to by url was last verified to support the text in the article". – Uanfala (talk) 12:40, 2 August 2018 (UTC)
  1. A date-of-last-working-URL isn't entirely useless, as it gives editors a chance to figure out which dates to focus on, if they're trying to find an archived copy of the link. It's probably also useful to the occasional reader. I expect people to be less surprised if a URL marked "Retrieved 1 January 2006" (NB: not "Checked" or "Verified" or anything like that – just "Retrieved") doesn't work, compared to a URL marked "Retrieved <yesterday>".
  2. The idea that it represents an editor (i.e., any editor after the person originally adding it) carefully determining that "the source actually verifies X" rather than "the source is present at this URL" appears to be wishful thinking. I don't think that I have ever seen anyone update these dates in a citation and say that they checked to make sure that the source truly supported the content; have you? However, I have seen editors check that a link is working/leads to the expected source more than a few times. Probably sometimes it's both (e.g., when the title of an article is sufficient to verify the content), but I've never seen someone mention doing both. WhatamIdoing (talk) 06:43, 4 August 2018 (UTC)
Well, if editors need a chance to figure out which dates to focus on when recovering a dead link, then what they actually need it is the date when the relevant text was found at the URL, not the date when that URL had any text whatsoever. As for the situations where editors update the access date, these are really rare: typically during large rewriting of articles (and hence when the sources have been consulted). Yes, I've seen editors fiddle with the access dates without bothering to check if the text there is actually the same text as the one used for the article, but that has been in the context of careless use of tools (like reFill, which very suggestively does not change the dates by default), but these editors have normally stopped when it was pointed out to them how citations work. Now, in light of the quotation from the template documentation above (sorry for not coming up with this earlier), it seems that your view is at odds with the way these templates are meant to work. If you would like to change the way they're supposed to work, you might want to make a an independent proposal to that effect. – Uanfala (talk) 09:21, 5 August 2018 (UTC)
  • Comment: I'm not sure about using accessdates for sources without a URL, although I have done it and don't see it as problematic. But, like SMcCandlish, I do prefer to use accessdates for book sources. As seen in this brief 2016 discussion, Sangdeboeuf (then known as Coconutporkpie) told me, "Template:Cite book states that this parameter is 'Not required for linked documents that do not change. For example, access-date is not required for links to copies of published research papers accessed via DOI or a published book, but should be used for links to news articles on commercial websites'." I told Sangdeboeuf that "like various other editors, I use accessdates for book sources...just like I add URLs or quotes for book sources; it's my style, and I do not intend on changing it." Checkingfax agreed with me, stating, "If a cite book template contains a URL I absolutely include an accessdate too. The cite book template example above provided by a Diff 'does' include a URL so for sure I would include an accessdate too. I used to include accessdates for all book cites but I have backed down. For one thing, if you include an accessdate and the cite does not already include a URL, then there will be a big red error code in the references section stating 'reference error: accessdate= requires url= (see: help)'. Books are not subject to WP:Link rot, but URLs to books are, and so books with URLs need accessdates too." In this 2017 discussion, we see that Trappist the monk, who deals with a lot reference cleanup, is against accessdates for books. He stated, in part, "The pu[r]pose of an access date is to identify the date on which an ephemeral source was consulted. For those sources that have nil chance of changing from one day to the next (books; encyclopedia; journal, newspaper, magazine articles; any on-line something with a doi, etc.) access dates are unnecessary, do not benefit the reader, and add to the clutter that is the reference section. For ephemeral sources (web pages, on-line news articles, etc), an access date is important because it allows the reader to hunt down an archived copy of the page as it was on the access date. [...] If it is necessary to determine when you added a cs1|2 template to an article, there is a tool to help you. At the top of every article's history page is a link Revision history search. For example: say that you want to know when you added the Ferri's Clinical Advisor 2013 template. Copy the title (best from the wiki source because the template or browser may have modified the what you see), go to the history page and click the history search link and paste the title into the 'Search for' box. Click the 'Start' button and get the result." Since then, I have employed Trappist the monk's style of no accessdate for book sources (using the vauthors template). Flyer22 Reborn (talk) 08:46, 28 July 2018 (UTC)
  • Yes, keep present behavior Under Verfiability policy, verifiability is not the same as access per Wikipedia:Verifiability#Access to sources. It's not 'verify date', it is 'access date' -- we should not have called it 'access date', if we wanted, 'verify date'. As a matter of practice, it is almost certain that when editors read the source again, they do not update the access date, so it is not last verification, it is about when the web-address was 'accessed' (and that is all it is). -- Alanscottwalker (talk) 09:42, 28 July 2018 (UTC)
  • Conditional treat lack of URL as correct. If someone can explain a plausible scenario where someone would use a changable computer source as a citable reliable source in Wikipedia, but that source is not accessible through a URL, then I will support having an access date with no URL, and rendering this access date in the article. Hypothetically I could imagine a room at a special library or government office where the public can go and look something up with terminals that are not connected to the Internet, or some sort of mobile phone app that lets you look stuff up but there is no URL. So can anyone give a real life scenario where something like that could happen? Jc3s5h (talk) 11:13, 28 July 2018 (UTC)
  • Create a new parameter - Having a parameter that tells us when someone last checked to see whether a citation actually supports the content is useful... but that is not the purpose of the “access date” parameter. The solution is to create a new parameter. Blueboar (talk) 12:31, 28 July 2018 (UTC)
    There is zero need for such a parameter. The words in books don't change when you put them away. Headbomb {t · c · p · b} 12:43, 28 July 2018 (UTC)
    The words in books don't change, but the text in our articles (supposedly supported by the book/website) does. SMcC is approaching this from the text side ... not the source side. He isn't really talking about the date that the source was added to the citation ... but the date that the text of our article was last checked against the source. Blueboar (talk) 22:11, 28 July 2018 (UTC)
    Ignoring the fact that this rationale has been refuted doesn't magically make it unrefuted. Repeat: The obvious problem with this analysis is that it's our own content that is more likely to change than any URL, very frequently resulting in WP:HIJACK. This is a massive hassle to track down, and is made much easier with an access date: you simply go directly to that date in the page history; on a busy page this can save a tremendous amount of time digging around trying to figure out when a cite was first added. This verifiability boosting effect has nothing to do with URLs. It's weird to me that people aware that the parameter can serve one function seem blind to the fact that it can serve another which is also important.  — SMcCandlish ☏ ¢ 😼  14:29, 28 July 2018 (UTC)
    There is a tool that allows one to find when a bit of wikicode was added so there is no loss. And can you depend on the access-date being what you expect because users may put when they accessed the book (2 years ago), not the date they added the citation which is what you're after and conceptually not the same as access-date. -- GreenC 14:56, 28 July 2018 (UTC)
    There's no need for a new parameter when this one works fine. It does not render when there's not URL, so it doesn't do anything confusing. Its presence in the wikicode, however, preserves the last verification date with is only something a editor doing WP:V checking is going to care about or see.  — SMcCandlish ☏ ¢ 😼  14:29, 28 July 2018 (UTC)
  • Keep current behaviour per User talk:CitationCleanerBot/Archive 1#Accessdates and above, since this is now a formal RFC. To recap, books and other offline resources are unchanging, it does not matter when you read the book, the words printed in it are no different in 2008 than in 2018. But also if you put a |access-date=28 July 2018 today, if someone finds a free link to the book in 2 years, and puts that up, then you'll have a wrong access-date suddenly display. There is zero benefit to anyone to know that Bob read a book on a specific date, it's the same book today as it was then. Access-dates only make sense you have url to go with them. Headbomb {t · c · p · b} 12:41, 28 July 2018 (UTC)
  • Comment - While such a parameter seems irrelevant for paper sources as the physical copy which is seen doesn't change - could this be relevant for ebooks and the like, as these might be subject to some sort of updates/changes after they have been initially downloaded?Nigel Ish (talk) 14:08, 28 July 2018 (UTC)
    Ebooks can have revision numbers. However a |accessdate= wouldn't help since it's still unknown what revision number is being referred to. In those cases, where revision matters, one should signify the ebook revision number.
  • Yes, keep current behavior It's confusing to use |access-date= for immutable sources, or sources that change according to revision ID (see comment above). -- GreenC 14:49, 28 July 2018 (UTC)
  • Yes, treat it as an error. Access dates should not be added to books; what date an editor read a book is irrelevant. Regarding other citation templates used for online sources, we need a URL for an access date to make sense. An access date is the date on which the URL was accessed. SarahSV (talk) 15:37, 28 July 2018 (UTC)
    • Do you have any estimate about how often a digital-only book might get updated/changed? The access date for a paper source (whether books or other media) is irrelevant, but I wonder whether some ebooks should be treated the same as a website. WhatamIdoing (talk) 06:46, 4 August 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

update to the live cS1|2 module weekend of 29–30 September 2018

I intend to update the live modules over the weekend of 29–30 September 2018

changes to Module:Citation/CS1:

changes to Module:Citation/CS1/Configuration:

  • withdraw support for |in= as a |language= alias
  • updated locks; discussion
  • implemented Module:Citation/CS1/styles.css
  • detect and categorize 'Archive copy' titles
  • remove hack for phab:T29786
  • |class= not supported with oldest arxiv identifier format; discussion
  • update OSTI URL; discussion
  • last 3 hidden error messages unhidden; discussion

changes to Module:Citation/CS1/Whitelist:

  • withdraw support for |in=
  • deprecate |class as basic parameter; discussion
  • deprecate |ASIN-TLD= (uppercase version); discussion

changes to Module:Citation/CS1/Identifiers:

  • |class= not supported with oldest arxiv identifier format

changes to Module:Citation/CS1/COinS:

—Trappist the monk (talk) 11:50, 23 September 2018 (UTC)

Cite and q element styling

I'm not sure we need to duplicate the CSS for the q and cite elements locally, since I don't expect those declarations to be removed from Common.css. Either way, I think this is some CSS that we can add later if we ever remove it from Common.css.
cite.citation {
	/* Reset italic styling set by user agent (only for cs1|2 templates; the
	reason for the .citation qualifier) */
	font-style: inherit;
}

q { /* Straight quote marks for <q> */
	quotes: '"' '"' "'" "'";
}
--Izno (talk) 15:53, 23 September 2018 (UTC)
That code is there for all of the other wikis that use the cs1|2 modules (as the comment in Module:Citation/CS1/styles.css points out); en.wiki's common.css is not shared by all wikis.
—Trappist the monk (talk) 16:51, 23 September 2018 (UTC)
Yes, that's true. However, that still introduces duplication with Common.css--readers at other wikis will now need to know to style their q and cite elements in both places otherwise they risk having disparate styles. --Izno (talk) 15:49, 29 September 2018 (UTC)

Citation-comment

@Izno re: this edit and this edit, are you sure? Class citation-comment is undefined so that editors may show or hide cs1|2 error messages using their own personal css (vaguely documented at Help:CS1_errors#Controlling_error_message_display; and certainly not to turn error messages green.
{{cite book/new |title=}} → {{cite book}}: Empty citation (help)
—Trappist the monk (talk) 15:36, 29 September 2018 (UTC)
Yeah, I saw that the class was being used slightly differently than I had interpreted it, just before you left a message. I created a new .cs1-maint to take the color and the display declaration and style. That should probably be refactored to use /Configuration since it is more like the error messages which are already captured there. That's a bit above my skill level though right now. --Izno (talk) 15:45, 29 September 2018 (UTC)
{{cite book}}: Empty citation (help). <- fixed, and the example above.
There also seems to be a really minor bug here where a space at the end gets injected into the maintenance span. We probably didn't know it was there because of Tidy; Remex doesn't strip internal space from HTML, which is why it is showing up.. --Izno (talk) 16:01, 29 September 2018 (UTC)
You are write that presentation for maintenance messages should be in /Configuration so I have done that. The space that you were seeing was a simple hack so that multiple maintenance messages were properly separated when rendered. That is now fixed in the sandbox:
Title. 2018. {{cite book}}: Unknown parameter |authors= ignored (help)CS1 maint: date and year (link).
—Trappist the monk (talk) 16:28, 29 September 2018 (UTC)

How do I format this date?

I have a reference whose correct publication date (according to JSTOR, changed only by conversion from hyphens to en-dashes) is "Fall–Winter 1988–1989". This results in a "Check date values" error message. How to format this date so that it is both accurate and non-complaining? (Noting in particular that "Fall 1988 – Winter 1989" would mean something different or at the least much more ambiguous, so is not sufficiently accurate.) —David Eppstein (talk) 21:13, 28 September 2018 (UTC)

Help:Citation Style 1 indicates the template does not support season ranges. So live with the false error message, or don't use citation templates. Jc3s5h (talk) 14:42, 29 September 2018 (UTC)
Where does H:CS1 say that?
{{cite journal |title=Title |journal=Journal |date=Fall–Winter 1988}} → "Title". Journal. Fall–Winter 1988.
—Trappist the monk (talk) 11:55, 30 September 2018 (UTC)
Or provide the actual date of publication. Or use another parameter. Or put that information outside of the template explicitly. Or put it in a comment in the date field. Lots of ways to work around it. This particular scenario has showed up before. --Izno (talk) 15:28, 29 September 2018 (UTC)
You can also use the |issue= parameter to give the "cover" issue date description above and use |date=1988 to specify when it was actually published. – Jonesey95 (talk) 16:10, 29 September 2018 (UTC)
So the consensus is: the template is incapable of formatting the date correctly? That's...helpful to know, I suppose. Is there a good reason why we don't have a workaround for "I know this really is a valid date even though it doesn't parse"? —David Eppstein (talk) 19:35, 29 September 2018 (UTC)
Elsewhere you rose in opposition when I suggested a form of markup that would instruct the module to accept this-input-as-written. So, no there is no such 'workaround'. You might write that date as |date=Fall–Winter 1988.
—Trappist the monk (talk) 11:55, 30 September 2018 (UTC)
On an aside, this has been discussed here and a discussion linked therein as well. --Izno (talk) 21:39, 30 September 2018 (UTC)

Remove |class= from non-cite arxiv templates

This is an arxiv-specific parameter, which is only useful when citing the preprints version. The only template that should support/display it is {{cite arxiv}}, or {{citation}} if no other identifiers are declared. Headbomb {t · c · p · b} 13:15, 24 July 2018 (UTC)

Are you sure? Shouldn't |class= be supported in {{cite journal}} when it has |arxiv=? Isn't what you really want a restriction that rejects |class= when |arxiv= is not present? But isn't |class= already ignored when |arxiv= is not present?
—Trappist the monk (talk) 13:51, 24 July 2018 (UTC)
Basically the only reason for |class= to be presented is when you cite the preprint as a preprint, since it gives you an idea of the moderation involved with it (general physics is the unfiltered shove-all repertoire where crank/junk ends up, although not all general physics is crank/junk). Once it's been reviewed, the version of record takes precedence over the arxiv version, so that information is pointless. Headbomb {t · c · p · b} 14:09, 24 July 2018 (UTC)
With the restrictions that you suggest, is there any real reason to support the notion of using {{citation}} to cite an arxiv paper? Because arxiv papers have not been published, there is no 'journal' or other periodical to tell {{citation}} how to render |title=. Without a periodical type parameter, {{citation}} renders |title= in italic font:
{{citation |vauthors=Abdurakhmanov UU, etal |title=Observation of Gaussian pseudorapidity distributions for produced particles in proton-nucleus collisions at Tevatron energies |arxiv=1807.01234 |class=nucl-ex}}
Abdurakhmanov UU, et al., Observation of Gaussian pseudorapidity distributions for produced particles in proton-nucleus collisions at Tevatron energies, arXiv:1807.01234 {{citation}}: Unknown parameter |class= ignored (help)
Of course, editors will make up something though the better solution is:
{{cite arxiv |mode=cs2 |vauthors=Abdurakhmanov UU, etal |title=Observation of Gaussian pseudorapidity distributions for produced particles in proton-nucleus collisions at Tevatron energies |arxiv=1807.01234 |class=nucl-ex}}
Abdurakhmanov UU, et al., "Observation of Gaussian pseudorapidity distributions for produced particles in proton-nucleus collisions at Tevatron energies", arXiv:1807.01234 [nucl-ex]
I think that the problem then reduces to:
if {{citation}} and |journal=<not set> and |arxiv=<set> then
error: |arxiv= ignored
elseif {{citation}} and |journal=<set> and |arxiv=<set> and |class=<set> then
error: |class= ignored
elseif not {{cite arxiv}} and |class=<set> then
error: |class= ignored
There is one other conditional that I can think of because the final published article may have been included in a book or conference proceeding:
elseif {{citation}} and |chapter=<set> and |arxiv=<set> and |class=<set> then
error: |class= ignored
—Trappist the monk (talk) 15:30, 24 July 2018 (UTC)
"is there any real reason to support the notion of using {{citation}} to cite an arxiv paper?" The only one I can think of would be for CS2 style (although here the title would be italicized, rather than quoted, and that's I believe wrong). I usually convert those to {{cite arxiv|mode=cs2}} when I can, so bots interact with them better. Also keep in mind that conference proceedings/book chapters can have arxiv links too, not only journals. |arxiv= should never be ignored. |class= should be, but only when the citation can be determined to be the version of record. IMO the best way to do that is to check for any other version-of-record identifiers in {{citation}} (so not CiteSeerX or SSRN), and kill |class= in any other {{cite xxx}} templates. Checking for journal/chapter would also likely be very efficient, so that could be certainly be a simpler alternative. I'd put this in a (hidden) maintenance category, rather than an (visible) error category. Headbomb {t · c · p · b} 19:54, 24 July 2018 (UTC)
[The] title would be italicized, rather than quoted... Yeah, that's why I asked if using {{citation}} to cite an arXiv preprint makes any sense. I don't think it does because the rendering is incorrect as is the template's metadata: &rft.genre=bookinstead of &rft.genre=preprint.
Do we have a list of cs1|2 supported identifiers that are version-of-record identifiers?
—Trappist the monk (talk) 14:16, 1 August 2018 (UTC)
AFAICT, arxiv/biorxiv/citeseerx/ssrn are not versions of records. The others are either exclusively (ISBN) or dominantly (DOI) versions of records, or just irrelevant (ISSN). Headbomb {t · c · p · b} 15:12, 1 August 2018 (UTC)
These are the supported identifiers broken up into groups as I understand them. Of the identifiers that are not version-of-record there is a group that is preprints, reviews, self-published sources, etc, and another group that is mostly catalog-like identifiers:
cs1|2 identifiers
version-of-record not version-of-record other
DOI, HDL, ISBN, ISMN, JSTOR, PMC, RFC, USENETID ARXIV, BIORXIV, CITESEERX, JFM, MR, OSTI, SSRN, ZBL ASIN, BIBCODE, EISSN, ISSN, LCCN, OCLC, OL, PMID
USENETID included here for completeness though it is only properly supported by {{cite newsgroup}}
Is this a correct categorization of these identifiers?
—Trappist the monk (talk) 13:21, 22 August 2018 (UTC)
cs1|2 identifiers
Version of Record[1] Preprints[2] Other[3]
DOI, ISBN, ISMN, JSTOR, LCCN, PMC, PMID, USENETID,[4] RFC ARXIV, BIORXIV, CITESEERX, SSRN ASIN, BIBCODE, EISSN, HDL, ISSN, OCLC, OL, JFM, MR, OSTI, ZBL
  1. ^ Usually, e.g. there are bioRxiv dois, ResearchGate dois, etc.
  2. ^ Usually, e.g. CiteSeerX is sometimes updated to host a published version.
  3. ^ Some are vendor-specific (ASIN), some are often but not always VoRs (BIBCODE), some are material related to a published version (ISSN, MR, JFM, ZBL), some are VOR/preprints hosted on a specific server (OSTI, HDL), and some are links to specific catalogues (OCLC).
  4. ^ USENETID included here for completeness though it is only properly supported by {{cite newsgroup}}
@Trappist the monk: Updated the table. Headbomb {t · c · p · b} 13:55, 22 August 2018 (UTC)
Restored my original table as a point of comparison for when I can return to this topic later.
—Trappist the monk (talk) 14:30, 22 August 2018 (UTC)
I have hacked Module:Citation/CS1/sandbox so that it emits an error message for the last three of the conditions I identified above:
{{citation/new |arxiv=1705.01263 |class=hep-ph |title=Title}} – no error message; {{citation}} used as a pseudo-cs2 version of {{cite arxiv}} (has malformed title)
Title, arXiv:1705.01263 [hep-ph] {{citation}}: Unknown parameter |class= ignored (help)
{{citation/new |arxiv=1705.01263 |class=hep-ph |title=Title |journal=Journal}}
"Title", Journal, arXiv:1705.01263 [hep-ph] {{citation}}: Unknown parameter |class= ignored (help)
{{citation/new |arxiv=1705.01263 |class=hep-ph |title=Title |encyclopedia=Encyclopedia}}
"Title", Encyclopedia, arXiv:1705.01263 [hep-ph] {{citation}}: Unknown parameter |class= ignored (help)
{{citation/new |arxiv=1705.01263 |class=hep-ph |title=Title |chapter=Chapter}}
"Chapter", Title, arXiv:1705.01263 [hep-ph] {{citation}}: Unknown parameter |class= ignored (help)
{{cite web/new |arxiv=1705.01263 |class=hep-ph |title=Title |url=//example.com}}
"Title". arXiv:1705.01263 [hep-ph]. {{cite web}}: Unknown parameter |class= ignored (help)
{{cite arxiv/new |author=Author |arxiv=1705.01263 |class=hep-ph |title=Title}} – no error message because {{cite arxiv}} and |class= used properly
Author. "Title". arXiv:1705.01263 [hep-ph]. {{cite arXiv}}: |author= has generic name (help)
There is, I think a better way than the special exception code that I wrote for this (and special exception code is generally bad and should be avoided when possible). |class= is a member of the basic_arguments whitelist which makes it available to all cs1|2 templates. Because |class= applies only to preprint sources, and only when |arxiv= or |eprint= is set, and because {{citation}} does not render |title= in the correct format without it also has a |work= alias or a |chapter= alias (both indicative of publication), I believe that there is no reason for {{citation}} to act as a pseudo-cs2 version of {{cite arxiv}}. Deleting |class= from the basic_arguments whitelist will give the Unknown parameter ... error without the need for special exception code.
While not discussed, and presumably not contemplated, there is a similar issue with |biorxiv= and |citeseerx= where {{citation}} will not correctly render preprints with these identifiers when |work= or |chapter= aliases are not set. Again, {{citation}} should not be used as a pseudo-cs2 versions of the {{cite biorxiv}} and {{cite citeseerx}} templates. We have |mode=cs2 for that.
—Trappist the monk (talk) 14:52, 24 August 2018 (UTC)

there having been no further discussion, |class= as a parameter accepted by all cs1|2 templates is deprecated. The special exception code in Module:Citation/CS1/sandbox is deleted.

—Trappist the monk (talk) 10:45, 15 September 2018 (UTC)

I just recently noticed this change due to the deprecation error note showing up while editing the upcoming "Recent research" feature for The Signpost, Trappist the monk and Headbomb. I usually include the |class= parameter whenever also using |arxiv= in {{cite journal}} or {{cite conference}}. With the deprecation now implemented, the error shows up in prior issues of "Recent research" where it is triggered. I can probably clean that up without much trouble, since I am the only one who added them as far as I am aware. I am posting here, however, because I noticed something that might be relevant and worthwhile to consider. Your input is appreciated.
Specifically, I often come across arXiv citations being formatted using {{cite journal}}, likely because {{cite arXiv}} is a far more obscure template among the CS1 templates and because it is far more restricted in its parameters. Many editors may also not understand why it matters to use the correct citation template, or otherwise think {{cite journal}} is just the catch-all template one uses for scientific articles. I know the differences, but that is because I regularly cite in CS1, have spent many hours reading the documentation, and have experimented with the templates enough to understand them better than the documentation sometimes documents. That is likely not the case for some editors, especially those with only a basic grasp on MediaWiki markup.
It is my understanding that |class= has been deprecated in non-{{cite arXiv}} CS1 templates because the purpose of that parameter is to provide some indication of "the moderation involved with" the preprint when citing "the preprint as a preprint". Given that preprints are frequently cited as preprints using {{cite journal}} or some other non-{{cite arXiv}} CS1 template, does the current deprecation of |class= conflict with the whole purpose of using the parameter?
Lastly, I apologize for having not brought this up earlier. As I said above, I only recently discovered this occurred due to the deprecation error message and I do not usually check this page (but probably should do so more often). —Nøkkenbuer (talk • contribs) 20:11, 30 September 2018 (UTC)
This, I think is the only question that you asked: Given that preprints are frequently cited as preprints using {{cite journal}} or some other non-{{cite arXiv}} CS1 template, does the current deprecation of |class= conflict with the whole purpose of using the parameter? No. The cs1|2 templates are confusing; there are lots of them and there are even more parameters. The use of error messaging is one way to educate those who use these templates (because you know, even when it's good, no one reads the documentation – except perhaps you – and the cs1|2 documentation is only just marginally adequate). The purpose of |class= is not to support improper use of the cs1|2 templates but rather, to lend credence to cited preprints using the only template that we have for that purpose. For a long time I have believed that |journal= should be a required parameter for {{cite journal}}. That, to me just seems like a no-brainer. I did not get any traction with that idea when I last raised it. Imposing that requirement might address arXiv citations being formatted using {{cite journal}}.
—Trappist the monk (talk) 22:04, 30 September 2018 (UTC)
Thank you for your input, Trappist the monk. It's entirely reasonable and I think justifies the deprecation; this change does not seem as such a loss to me now. —Nøkkenbuer (talk • contribs) 05:46, 1 October 2018 (UTC)

Work parameter and format of other parameters

The documentation says

When set,work changes the formatting of other parameters: [...] location and publisher are enclosed in parentheses.

Recently, making this edit, I observed that this does not seem to be the case. My citation was:

{{cite paper|url=https://fas.org/sgp/crs/natsec/R44137.pdf|title=Naval Station Guantanamo Bay: History and Legal Issues Regarding Its Lease Agreements|date=November 17, 2016|work=[[Congressional Research Service]]|publisher=[[Federation of American Scientists]]}}

Producing:

"Naval Station Guantanamo Bay: History and Legal Issues Regarding Its Lease Agreements" (PDF). Congressional Research Service. Federation of American Scientists. November 17, 2016.

Wtmitchell (talk) (earlier Boracay Bill) 08:57, 1 October 2018 (UTC)

This rfc removed parentheses from the publisher rendering. I've tweaked the documentation.
—Trappist the monk (talk) 09:46, 1 October 2018 (UTC)

Repeat linking of works/publications

Hello all, this is something I've wondered for awhile and have not been able to find a consensus/answers to, but I was curious as to whether or not a publication should be recurrently linked within the reference section of an article. In other words, for example, if ref. 1 of an article is Entertainment Weekly, is it necessary to re-link the publication in subsequent references from the same work? I've personally avoided this as I find it to be obtrusive when looking at the reference section as a whole (far too many Wiki links to the same publication), but this could be a biased perspective given that I am a frequent editor—it may prove useful for casual readers to have immediate linked access to the publication when hovering over individual footnotes as they read. I am unsure about how to handle this. Thank you. --Drown Soda (talk) 20:29, 29 September 2018 (UTC)

Standard (i.e., not just Wikipedia) citation practice is that every source used ("cited", "referenced", etc.; the terminology here is quite confused) in an article should have exactly one "full citation", with all of the bibilogrpahic details as my be useful in finding and identifying the source. On Wikipedia these full citations are most often created using a {{cite xxx}} or {{citation}} template. The most common practice on WP is to drop them into a note (footnote) created using <ref>...</ref> tags in the text. But you may note that many articles will collect all these full citations into their own section.
Your "repeat linking" question is commonly seen in the form of "how to 're-use' citations". There are two ways to do this. Most commonly seen at WP is the use of "named-refs", where a note – typically containing a full citation – is made to appear in more than one place. This implies having each full citation in its own note, and is what leads to those irksome strings of note links (e.g.: [1][7][27][15]...).
In the rest of world there are many ways of citing a source more than once. The most common way is to use the last name of the author (or authors) and year of publication, to link to the full citation. The easiest way to do this on WP is with the {{harv}} family of templates. And that is all I have time for now. ♦ J. Johnson (JJ) (talk) 00:23, 30 September 2018 (UTC)
@J. Johnson: your comments don't answer the OP's question as I read it at all. @Drown Soda: if multiple citations all come from the same publication, Entertainment Weekly is the name of the magazine/website being cited in footnote 1 and then cited in footnotes 3, 9 and 12, then I'd personally only wikilink to the article on the magazine in the first note and leave it unlinked in the others. Imzadi 1979 → 01:14, 30 September 2018 (UTC)
Well, I read the question slightly differently, there being some ambiguity in the meaning of "works/publications". Yet another example of why I am often askng for more precision in what people mean. ♦ J. Johnson (JJ) (talk) 00:10, 2 October 2018 (UTC)
@J. Johnson: I meant just that, as publisher/work are different fields in citation templates. The repeated wiki-linking of these was mainly what I was referring to. --Drown Soda (talk) 04:28, 2 October 2018 (UTC)
The term "references" is best avoided as having too many possible meanings, which are rarely (ever?) specified. E.g., where you said "subsequent references from the same work", "same work" implies a single source, and "subsequent references" thus suggests repetition of a single full citation. Which, as I explained at the outset, is wrong. Okay, so what you really meant (I gather) is wikilinking of data, such as the name of a publication, name of the publisher, place of publisher or publication, name of a work ("Encyclopedia Brittanica"), author's name, etc., that shows up more than once in a set of full citations to different sources. Well, that is good question; see below. ♦ J. Johnson (JJ) (talk) 21:49, 2 October 2018 (UTC)
@Imzadi1979: Thanks--this was what I felt made most sense. It seems my question was misunderstood by several other commenters here. I've been on Wikipedia for years and know how to use citation templates, name them in the reference brackets, etc. My question had to do with wikilinking publications in citations more than one time (i.e. suppose an article references three different articles from The New York Times—do I wikilink The New York Times in each citation, or only the one that first appears?). Linking the publication in every single citation overwhelms the reference section in my opinion and results in excessive links, but as I said, I am not sure there has been a consensus on this among editors. --Drown Soda (talk) 01:40, 30 September 2018 (UTC)
There was some discussion of this earlier this year at a venue marginally more appropriate than this one. --Izno (talk) 06:34, 30 September 2018 (UTC)
The rough consensus I'm seeing out of these discussions is actually (surprisingly to me) to link everything, always and then modify that with common sense: publication location should normally not be linked by the same rationale that place names should generally not be linked in prose; dates and years should not be linked as with in prose; author names, publishers, and works should not be redlinked unless the relevant datum is fairly clearly notable; and so forth. I've been practicing that for a long time but with the expectation that someone would eventually jump down my throat for it; but the discussion linked above, and a previous discussion here, suggests that the rough consensus among the parts of the community participating in those discussions is mainly in favour of linking. There will be disagreements on details, certainly, and local consensus still decides for any given article; but I think the general guidance now is to link all the most important parameters (title, author, publisher, publication) that have Wikipedia articles, and to not redlink any of them unless the target is clearly notable. --Xover (talk) 07:38, 30 September 2018 (UTC)
@Xover: I was wondering about consensus on it as well; my only hang-up is that it leaves the reference section full of multiple wikilinks to the same page, which is not acceptable in the body of the article. --Drown Soda (talk) 04:28, 2 October 2018 (UTC)
@Drown Soda: The consensus I'm seeing in these discussions is that the references are not article prose and thus the usual concerns for OVERLINK do not apply. And I agree with that: "sea of blue" doesn't really matter in the references because it's a list of metadata, not prose that needs to be readable primarily. --Xover (talk) 08:17, 2 October 2018 (UTC)
I generally agree with Xover. First choice would be to restructure the citation scheme so a work only appears once in the reference list. But if that seems too complex to the editors who maintain the article, the second choice would be to link it every time, because when the reader arrives at the reference list, the reader is only focused on the source that supports the claim of interest; the reader probably isn't going to read the entire reference list and so will not be aware the publisher is linked somewhere else. Jc3s5h (talk) 14:08, 2 October 2018 (UTC)
Jc3s5h: it appears you are under the same misunderstanding I was. He wasn't asking about repeat citations of a given work, but duplicate wikilinking (to articles) of data (names of publications, etc.) that is used multiple times. I don't believe there is any "citation scheme" where one could (for instance) "reference" (cite?) the New York Times only once. But check out 2014_Oso_mudslide#References, where the articles from several newspapers are listed under the newspaper, and the name of the paper can be wikilinked independently of any of the included citations.
I generally agree with Xover, except that I am usually too lazy to wikilink everything. ♦ J. Johnson (JJ) (talk) 21:59, 2 October 2018 (UTC)
@J. Johnson: I wasn't quite sure what the OP was referring to. The various methods of completely combining citations, or using a mixture of short and full citations, can reduce, but not eliminate, the repetition of certain facts, such as Oxford University Press being a publisher, or that University Science Books is located in Mill Valley, California. Using these techniques for brevity can reduce the number of wikilinks, but not always reduce them to one wikilink per Wikipedia article. I personally do not routinely link publishers or publisher locations, but I might if the Wikipedia article adds information about a publisher or place that isn't common knowledge. (For example, from its name, many readers might not guess that Cooper Union is a college.)

Archived title

Can somebody please create a CS1 maintenance error message for when the title of a citation template is "Archived copy"? Since no webpage is named this, but we still have over 100,000 such hits (Special:Search/insource:/title\=Archived copy/). This should be tracked and worked on, to replace with the real webpage title, manually or with a bot. (t) Josve05a (c) 21:44, 23 July 2018 (UTC)

Based on this edit (a sample size of one), it looks like you might want to file a bug with InternetArchiveBot. – Jonesey95 (talk) 00:22, 24 July 2018 (UTC)

"Archived copy" is standard wording used by multiple tools/bots in the same situation of not being able to determine the title, so it's easy to track with a search. If users will tackle it manually or with AWB by all means create a tracking category. Ideally it would be done by a specialized title bot since there are likely endless edge cases to deal with when extracting title data. -- GreenC 02:02, 24 July 2018 (UTC)

I have added case-insensitive detection of this title to Module:Citation/CS1/sandbox and added a new maintenance category to Module:Citation/CS1/Configuration/sandbox:
{{cite web/new |url=http://www.numa.net/expeditions/u-21_1.html |title=Archived copy |access-date=2 November 2008 |archive-url=https://web.archive.org/web/20081227004917/http://www.numa.net/expeditions/u-21_1.html |archive-date=27 December 2008}}
"Archived copy". Archived from the original on 27 December 2008. Retrieved 2 November 2008.{{cite web}}: CS1 maint: archived copy as title (link)
'Archived copy' is not recognized as an 'invalid' title when |archive-url= is not set:
{{cite web/new |url=http://www.numa.net/expeditions/u-21_1.html |title=Archived copy |access-date=2 November 2008}}
"Archived copy". Retrieved 2 November 2008.
—Trappist the monk (talk) 12:17, 30 July 2018 (UTC)
@Trappist the monk: Looks good! Anyway to implement this live? (t) Josve05a (c) 18:10, 20 August 2018 (UTC)

@Trappist the monk: - it appears "Archive copy" is also being used. -- GreenC 12:31, 23 September 2018 (UTC)

tweaked:
"Archive copy". Archived from the original on 27 December 2008. Retrieved 2 November 2008.{{cite web}}: CS1 maint: archived copy as title (link)
—Trappist the monk (talk) 12:46, 23 September 2018 (UTC)
??? This is a web page citation. The particular web page has a title, all one has to do is look at the source: <title>Story of the U-21 </title>. Conveniently, this is also the cited web page's rendered heading. The documentation for {{cite web}} is clear on this (Template:Cite Web#Title). The fact that the encapsulating archive page has its own (html) title is irrelevant. The underlying archive is what is cited. The technical detail that this is an archived copy is handled elsewhere in the citation. The citation in question is not edited correctly, and "Archived copy" should not be used when the title is available. 108.182.15.109 (talk) 14:07, 5 October 2018 (UTC)
"All one has to do.." makes the assumption title data is clean, accurate and ready to be cut and pasted into a Wikipedia citation. There are all sorts of crazy things in the <title></title>. There was a title bot (forget name) that did this and left an inline comment the title was created by bot, and more often than not those titles need manual cleanup. For some reason the bot owner is no longer operating it. Point is, title bots are not trivial and require a fair amount of effort to watch over. It's beyond the scope of other bots and tools to individually create their own title bot routines, not even considering the network I/O overhead of polling each link when they might not otherwise need to. If you want to help by creating a title bot that would be awesome but not if it's pasting in title data blindly, it should be looking for edge cases and building up a system to detect and fix repeatable problems. -- GreenC 14:36, 5 October 2018 (UTC)
I think you misunderstood the point I was making. The cited citation is malformed. This has nothing to do with bots. Editors should be given the correct guidance: when the title of a webpage is not obvious, they should look at the source, and specifically search for the <title> element. Internet Explorer (the browser I am using right now) has a "Page" dropdown menu in the Command toolbar, that includes a "Properties" option. When you click this, the title of this page as I edit it ("Editing Help talk:Citation Style 1 (section) - Wikipedia") is right at the top. I'm not saying that IE should be used. But a diligent editor is supposed to look at this, just as they are supposed to look at a book's or journal's front and back matter for edition/copyright info, etc. etc. A citation with "Archived copy" as title should not be "fixed" to conform with cs1 presentation. It should be flagged so that editors are alerted that something is amiss. Because I think that an automated routine to fix this is more likely to mess things up. Another option is to substitute the (visible) top heading for the webpage's title, even if this is technically incorrect. Although this may not be the way pages are indexed (and therefore retrieved) by software looking for the webpage's metadata, it would be sufficient for humans looking for the page's data. 72.43.99.138 (talk) 14:57, 6 October 2018 (UTC)
It's true that "Archived copy" doesn't flag or notify users to fix the missing title. Would you suggest a different wording, or red warning message, or populate a tracking category? -- GreenC 15:13, 6 October 2018 (UTC)

Separators in |language= parameter

When |language= contains two values, in the output they are separated with " and ".

  • {{cite book|title=Title |language=fr,de}}
  • Title (in French and German).

When it contains three or more values the final two are separated with ", and ".

  • {{cite book|title=Title |language=fr,de,it}}
  • Title (in French, German, and Italian).

There is not an option to modify or translate the separators in Module:Citation/CS1/Configuration. However, it contains two local messages ['parameter-final-separator'] = and ['parameter-pair-separator'] = which would be useful in this case. Is it possible to enable these local messages in |language=? I regularly update CS1 modules in el.wikipedia.
Αντιγόνη (talk) 19:06, 7 October 2018 (UTC)

Thanks for pointing out that omission. Fixed in the sandbox using cfg.messages['parameter-pair-separator']:
{{cite book/new |title=Title |language=fr,de}}
Title (in French and German).
{{cite book/new |title=Title |language=fr,de,it}}
Title (in French, German, and Italian).
—Trappist the monk (talk) 19:38, 7 October 2018 (UTC)
Thank you for your fast response, I would like to insist in using ['parameter-final-separator'] or equivalent syntax though. I omitted to mention earlier that in greek (el), perhaps in other languages too, comma is not placed before "and", not only in pairs but also in longer lists. Therefore, the correct output in greek would be:
  • {{cite book|title=Title |language=fr,de,it}}
  • Title (in French, German and Italian).
I think that ['parameter-final-separator'] or equivalent message would allow greater flexibility to satisfy both cases, with or without comma before "and", by modifing it accordingly.
Αντιγόνη (talk) 21:28, 7 October 2018 (UTC)
ok. done.
—Trappist the monk (talk) 22:29, 7 October 2018 (UTC)

"Dashes in the ISBN are optional"

They are hyphens, not dashes. Pleas correct. — Mikhail Ryazanov (talk) 09:41, 9 October 2018 (UTC)

Can you show a live example of what you mean?
—Trappist the monk (talk) 10:03, 9 October 2018 (UTC)
The complaint was about the documentation (now fixed). Kanguole 11:07, 9 October 2018 (UTC)

Regressions: advice request

In Russian Wikipedia, {{cite journal}} is used mainly in translated articles. Its current ruwiki version is a slightly edited many-years-old version of the enwiki template. I was going to replace it with the current enwiki version based on the CS1 family of modules, but it turned out that along with many improvements it would cause some regressions. Here is a random sample of cite_journal transclusions in ruwiki; left — current ruwiki version, right — current enwiki version. As can be seen, there are 4 main issues:

  • error regarding unrecognized language and tracking categories for sources in particular languages with mixed English-Russian names;
  • "month" is ignored and emits an error;
  • "access-date" requires "url" and emits an error;
  • "coauthors" is ignored and emits an error.

The last point is particularly painful because the main problem with the current ruwiki version of this template is that it ignores parameters like first1, last1, etc. So we end up with not showing author lists when using either of the two versions (but in different cases).

Of course, it is the responsibility of the ruwiki community to deal with this issue. All I wanted to ask is an advice about the best way to deal with these regressions. Some bot run? Some config edits? Something else?

--colt_browning (talk) 12:30, 9 October 2018 (UTC)

None of your primary issues are 'regressions', as in, unintended changes. All of them were deliberate. (I see some other deltas, such as quotation marks, that look like they are because you have not set up your configuration/styles modules all the way.)
  1. Templates with |month= and |year= (if not also |day=) can be botted to |date= (as in, |date=(day) month year). Others should probably be case-by-case fixes.
  2. Many times this is due to a non-web resource, or a web-resource with a permanent ID of some sort (e.g. |doi=), having been accessed on that date, which is not the purpose of that parameter. Those cases can be botted. The others should be case-by-case cleaning.
  3. |coauthors= is preferably split to |authorn= or first/lastn. If that's a pain point (say your coauthors are separated inconsistently), |authors= is also available.
You ECd with me so my bullets refer only to the later 3. --Izno (talk) 14:05, 9 October 2018 (UTC)
Thanks. I didn't mean to criticize; I didn't mean that these changes were regressions when they were introduced here; I meant that they would become regressions in ruwiki if we just replace the old version with the new one. --colt_browning (talk) 14:20, 9 October 2018 (UTC)
No worries--it was clear from context you didn't meant to criticize :). --Izno (talk) 14:46, 9 October 2018 (UTC)
I don't see an error regarding languages. Do you have an example of that? --Izno (talk) 14:10, 9 October 2018 (UTC)
Category: CS1 maint: Unrecognized language. It is caused by samples No. 4, 18, 70, where the name of the language is given instead of its code. --colt_browning (talk) 14:20, 9 October 2018 (UTC)
You might be able to look through the history of this talk page and the history of edits to the module pages in order to pick out an intermediate version of the template that is more forgiving. |coauthors=, for example, was deprecated but still supported for a while, and then after a long while, support was removed entirely. I think that |month= went through the same transition, but it's been a while. You'll have to look back in the edit history, where changes to the module pages and sandbox pages are listed in comments. – Jonesey95 (talk) 14:23, 9 October 2018 (UTC)
(edit conflict)
Yikes! that is old.
I guess that step one is for the ru.wiki community to decide that they want to upgrade to the cs1|2 module suite and that they want to do it for all of the cs1|2 templates. Seems silly to me to retain the old old old wikitext versions of some templates but use new for others.
The unrecognized language issue occurs because at ru.wiki, the code expects the value assigned to |language= to be Russian orthography or ISO 639-1 code (Latn script); instead of |language=French, write: |language=французский or |language=fr. One of the things that I have thought to do is to tweak the language parameter code so that it first tests the language value against the local language list. If that fails ('French' not found in the ru.wiki language list), try again with the English language list. If you go ahead with this project, it will be a useful test-bed for this idea.
We elected to deprecate and remove |month= and |day= because too many date parameters are too many date parameters; because Lua is much more capable than parser functions and wikitext; because we had no need for such data granularity (and if we develop such a need, the component parts of a date can easily be extracted from a whole date). Editors here wrote AWB scripts that trolled through one or more of the error categories and rewrote |day=, |month=, |year= into |date=. Were it me, I would do the same at ru.wiki.
Our documentation here has always associated |access-date= with |url= as a date that the citing editor confirmed that the source linked by |url= supported the text our article. Identifier sources, doi, pmc, etc are 'permanent' so will not be changing unlike many web-based sources.
We elected to deprecate and remove |coauthor= and |coauthors= because cs1|2 produces COinS metadata; because too many author parameters are too many author parameters; editors here ignored the plural / singular distinction. COinS does not have support for multiple names in a single key/value pair – COinS expects the name of one author for each instance of &rft.au so none of the authors listed in either of |coauthor= and |coauthors= was included in the metadata. For this same reason, the value assigned to the plural |authors= is also not included in the metadata. Converting |coauthor= and |coauthors= to |authorn= (not to |authors=) required several AWB scripts (to find and fix the low-hanging fruit) and a lot of manual fixes. This is the most difficult of the tasks ahead of you because human names are endlessly variable as are the ways that editors choose to represent those names in cs1|2 templates.
If after reading all of that you still wish to proceed, I would strongly recommend that you do a careful and complete translation of Help:CS1 errors. I don't know if it is possible but if it is, import the entire Category:CS1 category because all of those sub-categories are intimately tied to the cs1|2 templates and to Help:CS1 errors. Import rather than copy because there are a lot of category pages so if it can be done all in one go, do that. In ru:Module:Citation/CS1/Configuration at a minimum, translate the error messages and the ['help page label'] value so that general editors in the ru.wiki community who don't have English can understand what all of that red text means.
When you 'flip-the-switch', regardless of how much advance warning you have given, there will be angry editors. There is no getting away from that.
If you need help with technical issues or you see places where the cs1|2 internationalization support can be improved, give a shout. Good luck.
—Trappist the monk (talk) 14:24, 9 October 2018 (UTC)
Thank you very much! --colt_browning (talk) 14:43, 9 October 2018 (UTC)

New stripmarker error in Template:Ford1922

There is a new stripmarker error in Template:Ford1922, a template that has not been edited for almost a year. Should this be fixed in the template or in the CS1 modules? Thanks. – Jonesey95 (talk) 04:41, 10 October 2018 (UTC)

Misuse of |postscript= is the problem in each of these. I would guess these are also causing lint errors on their respective pages. --Izno (talk) 05:15, 10 October 2018 (UTC)
That fix works for me. Thanks. – Jonesey95 (talk) 08:18, 10 October 2018 (UTC)

Url-access parameter for Cite encyclopedia – Reason missing from full parameter list?

Anyone know? May I add it? I would not have even known it was an option except saw the icon used and was digging around in the code. Are there other parameters that are excluded? Reason for those? Thanks, Peacedance (talk) 21:33, 10 October 2018 (UTC)

Probably because I / we suck at documentation. Any help that can be had making the cs1|2 documentation better is gratefully accepted.
—Trappist the monk (talk) 22:15, 10 October 2018 (UTC)

Urgent: Dash errors

  • <pre>{{cite journal |last=Smith |first=J. |year=1948–1950 |title=Foobar |journal=Whatever |pages=1654–1055}}</pre>

Renders as

  • Smith, J. (1948–1950). "Foobar". Whatever: 1654–1055. {{cite journal}}: Check date values in: |year= (help)CS1 maint: year (link)

Rather than

  • Smith, J. (1948–1950). "Foobar". Whatever: 1654–1055.

@Trappist the monk:.Headbomb {t · c · p · b} 21:24, 11 October 2018 (UTC)

Help talk:Citation Style 1#ndash entity in pages parameter
—Trappist the monk (talk) 21:38, 11 October 2018 (UTC)
Well, this should be deployed now, not in weeks. Thousands if not hundreds of thousands of citations are now borked. Headbomb {t · c · p · b} 21:48, 11 October 2018 (UTC)
10000 Galobtter (pingó mió) 07:33, 12 October 2018 (UTC)
That's articles. Multiple citations per articles increase the count. Headbomb {t · c · p · b} 23:03, 13 October 2018 (UTC)

Removed support for 'interviewers'

I have removed support from the sandbox module for |interviewers= as Category:CS1 maint: Uses interviewers parameter‎ has been empty for some time (and spurred by a comment Ttm made when he added support for enumerated interviewers).

  • Current: "Title" (Interview). {{cite interview}}: Unknown parameter |interviewers= ignored (help)
  • Sandbox: "Title" (Interview). {{cite interview}}: Unknown parameter |interviewers= ignored (help)

The category can be deleted when the sandbox is next deployed. --Izno (talk) 04:54, 15 October 2018 (UTC)

That would be this comment?
—Trappist the monk (talk) 12:07, 15 October 2018 (UTC)
Indeed. --Izno (talk) 12:54, 15 October 2018 (UTC)

Template: Cite journal - Mistaken use of attribute "Volume"

I encountered a very far-spread problem with the use of the "volume" parameter of this template. According to the docs, the parameter expects an entry like "Volume four", "Vol. 4", "Band VII", etc. If anything shorter than 4 characters is entered, this is printed in bold text in the citation, to mark the mistake.

Nearly all uses of the template seem to ignore this. The result is a host of Volume descriptors, that are nothing but bold printed numbers. This could lead to misunderstandings and confusion among users trying to find the cited journal article. For an impression of the extent of the mistaken use, look at Candide#Sources, for example. Or really any article citing lots of journals.

On IRC, Huon proposed to change the code so that a regular error message is produced instead of just bolding the too short entry. This would prevent future mistaken use. If considered important enough, perhaps the existing countless issues of mistaken use should also be fixed. 2.247.243.131 (talk) 16:17, 17 October 2018 (UTC)

I think that you are mistaken. The bolding that you describe is not to be understood as an indication of error; it is simply the style that is applied to |volume= values that are shorter than five characters.
—Trappist the monk (talk) 16:24, 17 October 2018 (UTC)
Ok, my mistake then. Are you sure that this is according to an existing convention that most users can understand? 2.247.243.131 (talk) 16:26, 17 October 2018 (UTC)
It is the convention that cs1|2 has used for journal cites for a very long time, in fact, the bolding was present in the very first version of {{cite journal}}.
—Trappist the monk (talk) 16:30, 17 October 2018 (UTC)
For more context, some outside style manuals call for the volume number of a journal to bolded. Volume numbers usually start at 1 the year the journal is founded, and go up by 1 each year. If the volume parameter is short, it's assumed to follow this convention, and gets bolded. If it's long, the template assumes the convention is something the template doesn't understand, and the value is not bolded. Jc3s5h (talk) 16:44, 17 October 2018 (UTC)

Hacking around templatestyles and T205803

FYI, I changed Template:Philippine census reference to (1) call "Template:Philippine census reference/strip" to strip the templatestyles from the citation template output, and (2) add the templatestyles back outside of the reference tag. this is a total hack workaround for T205803 which was triggered when templatestyles were added to Module:Citation/CS1. clearly this is a fragile hack fix since it relies on the format and position of the ocins (specified in Module:Citation/CS1/Configuration) and the fact that the templatestyles is at the end. so, please let me know if you have a better solution or if T205803 is fixed so I can undo my changes. Frietjes (talk) 16:18, 13 October 2018 (UTC)

Update, since this is a broader problem, I have implemented something in Module:Citation/CS1/templatestyles, which appears to work as well, but seems to be less fragile. Frietjes (talk) 14:15, 14 October 2018 (UTC)
So a patch was uploaded but not merged which I expect will come on the WP:THURSDAY software deployment. --Izno (talk) 16:47, 14 October 2018 (UTC)
excellent, once that is merged, I will orphan the module and have it deleted. until that happens, Category:Pages with duplicate reference_names is becoming more useful (down from over 5K entries yesterday). Frietjes (talk) 17:34, 14 October 2018 (UTC)
A similar issue with {{Certification Table Entry}} has resolved itself, so the patch may already be live. --Muhandes (talk) 15:24, 17 October 2018 (UTC)
looks like the patch has been merged, so I have removed the hack from the ca. 9 templates that were using it. it could be useful to keep the hack module around in case, or we could probably just delete it. Frietjes (talk) 23:46, 18 October 2018 (UTC)
Since you're the one who made significant contributions, you can submit it for author-only CSD. I'd support that. --Izno (talk) 00:50, 19 October 2018 (UTC)

Broken templates

Tracked in Phabricator
Task T205803

{{Inflation/fn}} was apparently broken by a change to Module:Citation/CS1 on 29 September. Can we revert it until we have a fix? Hawkeye7 (discuss) 22:54, 13 October 2018 (UTC)

At least a few other templates were affected, too. -- Mikeblas (talk) 01:55, 14 October 2018 (UTC)

{{Inflation/fn}} was not broken by the 29 September update to the cs1|2 module suite. Rather, the problem lies with the MediaWiki software. I said as much at Template_talk:Inflation/fn#duplicate_reference_definitions, a discussion to which you both have contributed. This is not the place to fix a problem in the MediaWiki code. Reverting the last module suite update will not repair the underlying problem, only mask it. —Trappist the monk (talk) 10:39, 14 October 2018 (UTC)

You're saying that there was a change to the MediaWiki software on that date which should be reverted? Hawkeye7 (discuss) 19:44, 14 October 2018 (UTC)
No. MediaWiki was flawed before the 29 September 2018 module update but no one knew it. The module update revealed the flaw. I am saying that the proper solution is to fix MediaWiki, which apparently has been done and is just waiting for review and implementation; see §Hacking around templatestyles and T205803.
—Trappist the monk (talk) 20:06, 14 October 2018 (UTC)
I have a bug fix request in Phabricator that is over six months old now. Changes to MediaWiki code are potentially highly disruptive. We should neither expect nor rely on MediaWiki changes, especially if we can handle it here. Hawkeye7 (discuss) 20:36, 14 October 2018 (UTC)
Aye, sometimes phabricator is just like that black hole at the back of the laundry where single socks go; I have one there from June 2016. But so what? That doesn't change the fact that the correct place to fix this problem is at MediaWiki.
—Trappist the monk (talk) 22:56, 14 October 2018 (UTC)
It seems like the course of action followed was to make a change that identified an issue in MediaWiki, then leave the broken code in place, blaming MediaWiki. That leaves the site broken. Do I have it right? If no, what am I missing? If so, how is that really what's best for the site and its users? -- Mikeblas (talk) 09:51, 15 October 2018 (UTC)
MediaWiki enabled TemplateStyles at en.wiki 19 July 2018. On that same day I created what would become Module:Citation/CS1/styles.css and started this discussion. Between then and the 29 September update we modified the cs1|2 modules and styles.css to move inline style from the modules into styles.css (where it belongs). More than two months after TemplateStyles was enabled, we implemented it. On that day you noticed that {{Inflation/fn}} produced duplicate reference definition errors. I learned of the problem on 30 September and on that day diagnosed the problem which caused you to open phab:T205803. Also that day and on 1 October, developers at MediaWiki confirmed the problem. One of them created a fix that was uploaded for review on 14 October which some here believe will deployed 18 October.
The broken code is not in TemplateStyles and is not in cs1|2 but is in MediaWiki's mw:Extension:Cite/Cite.php (the prospective fix).
You can use the word blame if you'd like. I prefer to think that we diagnosed a problem and notified the cognizant people who have done whatever it is that they do to confirm the diagnosis and create a remedy. Yes this problem manifests itself in a way that causes grief for certain templates. Editor Frietjes has applied a clever hack to {{Inflation/fn}} and to a handful of other templates. Still, the cs1|2 modules are used on about 3.8 million pages. For the vast majority of those pages, this problem is not a problem.
—Trappist the monk (talk) 11:26, 15 October 2018 (UTC)
Index: pl ar de en es fr it arz nl ja pt ceb sv uk vi war zh ru af ast az bg zh-min-nan bn be ca cs cy da et el eo eu fa gl ko hi hr id he ka la lv lt hu mk ms min no nn ce uz kk ro simple sk sl sr sh fi ta tt th tg azb tr ur zh-yue hy my ace als am an hyw ban bjn map-bms ba be-tarask bcl bpy bar bs br cv nv eml hif fo fy ga gd gu hak ha hsb io ig ilo ia ie os is jv kn ht ku ckb ky mrj lb lij li lmo mai mg ml zh-classical mr xmf mzn cdo mn nap new ne frr oc mhr or as pa pnb ps pms nds crh qu sa sah sco sq scn si sd szl su sw tl shn te bug vec vo wa wuu yi yo diq bat-smg zu lad kbd ang smn ab roa-rup frp arc gn av ay bh bi bo bxr cbk-zam co za dag ary se pdc dv dsb myv ext fur gv gag inh ki glk gan guw xal haw rw kbp pam csb kw km kv koi kg gom ks gcr lo lbe ltg lez nia ln jbo lg mt mi tw mwl mdf mnw nqo fj nah na nds-nl nrm nov om pi pag pap pfl pcd krc kaa ksh rm rue sm sat sc trv stq nso sn cu so srn kab roa-tara tet tpi to chr tum tk tyv udm ug vep fiu-vro vls wo xh zea ty ak bm ch ny ee ff got iu ik kl mad cr pih ami pwn pnt dz rmy rn sg st tn ss ti din chy ts kcg ve
Prefix: a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9

Portal di Ensiklopedia Dunia

Portal : Agama
Agama
Portal : Bahasa
Bahasa
Portal : Biografi
Biografi
Portal : Budaya
Budaya
Portal : Ekonomi
Ekonomi
Portal : Elektronika
Elektronika
Portal : Film
Film
Portal : Filsafat
Filsafat
Portal : Geografi
Geografi
Portal : Indonesia
Indonesia
Portal : Ilmu
Ilmu
Portal : Lingkungan
Lingkungan
Portal : Masyarakat
Masyarakat
Portal : Matematika
Matematika
Portal : Militer
Militer
Portal : Mitologi
Mitologi
Portal : Musik
Musik
Portal : Olahraga
Olahraga
Portal : Pendidikan
Pendidikan
Portal : Politik
Politik
Portal : Sastra
Sastra
Portal : Sejarah
Sejarah
Portal : Seni
Seni
Portal : Teknologi
Teknologi
Kembali kehalaman sebelumnya