Wikipedia talk:Citing sources
This is the talk page for discussing improvements to the Citing sources page. |
|
Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56Auto-archiving period: 2 months |
|
To find archives of this talk page, see this list. For talk archives from the previous Manual of Style (footnotes) page see Help talk:Footnotes. |
This project page does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||
|
Index 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 |
This page has archives. Sections older than 75 days may be automatically archived by Lowercase sigmabot III when more than 5 sections are present. |
No known day?
I often cite scholarly sources in which a publication day is not known. I prefer to use a single canonical format for date specification. If, as the page states "Because it could easily be confused with a range of years, the format YYYY-MM is not used", how do you specify a date with a known year and month, but no day? -Reagle (talk) 14:27, 30 April 2020 (UTC)
- The format "DD Month YYYY" can be used for eliding days, but that then is dependent on English (or whatever language). -Reagle (talk) 14:27, 30 April 2020 (UTC)
- Short answer, you cannot per the MOS. If you need to cite in other languages, you will need to use their style guide anyway. --Izno (talk) 15:08, 30 April 2020 (UTC)
Example:
{{cite magazine |magazine = IEEE Spectrum | title = Quantum computers scale up | last = Versluis | first = Richard | pages = 25–29 | date = April 2020 | ref = none}}
- Versluis, Richard (April 2020). "Quantum computers scale up". IEEE Spectrum. pp. 25–29.
Jc3s5h (talk) 13:08, 13 May 2020 (UTC)
- A case that could come up is all the citations already in the article use the format YYYY-MM-DD or YYYY for dates, which is allowed in MOS:DATES. However, the "Manual of Style/Dates and numbers" is merely a guideline, and is superseded by the "Verifiability" policy, so your need to give a month and day, combined with the possibility of genuinely confusing readers if a date were given as, for example, "2011-12", creates a need to change all the citations in the article away from the YYYY-MM-DD format to some other acceptable format. Jc3s5h (talk) 13:52, 13 May 2020 (UTC)
- Not all the dates in citations should be changed, since it is allowed to use YYYY-MM-DD dates in access and archive dates when they are not used in the date of the source itself. Only change the format of the date of publication. Peter coxhead (talk) 09:13, 14 May 2020 (UTC)
- I don't necessarily agree with Peter coxhead. MOS:DATEUNIFY states "Publication dates in an article's citations should all use the same format". Since a revision in the citation date format would be needed, it would be up to the discretion of the editor adding the source that a month, but not a day, of publication to decide whether the reformatting should extend to access and archive dates. After all, it is difficult to discern whether the editor(s) who chose to make all the citation dates in the YYYY-MM-DD format had a separate intent to put the publication dates and the archive & access dates in that format, or whether the original intent was to have them all in the same format. Jc3s5h (talk) 12:12, 14 May 2020 (UTC)
- Not all the dates in citations should be changed, since it is allowed to use YYYY-MM-DD dates in access and archive dates when they are not used in the date of the source itself. Only change the format of the date of publication. Peter coxhead (talk) 09:13, 14 May 2020 (UTC)
- I have been pointing this problem out for years. Let's say we have an article that has 20 references and all of them use yyyy-mm-dd for dates. Then somebody wants to add a magazine article that has year and month but not day of month. MOS:DATEFORMAT does not allow us to yyyy-mm, so we have to use mm-yyyy. But then WP:DATEUNIFY kicks in which says to not mix formats. So the editor converts all reference dates to dd-mm-yyyy (or equally arbitrarily mm-dd-yyyy). But that goes against MOS:DATERET and possibly against the wishes of the other editors. There is no action to add this reference that satisfies all our rules.
- It is often said that yyyy-mm can be confused with a date range, ie 2001-02 (Feb 2001) might be mistaken for the year range 2001-2002. Taken at face value, this is a legitimate point. However, that date is not sitting there alone. It is sitting among a whole pile of other dates like 2001-02-28, 2000-12-31, 1999-01-29, etc. When you see a lot of dates in that format it is natural to assume that the new date also matches the same order as the rest. Also, a couple of years back we deprecated yyyy-yy 2 digit date ranges in favour of yyyy-yyyy 4 digit date ranges. Since yyyy-yy is not allowed, that leaves yyyy-mm the only valid way to interpret a date like 2001-02.
- That's a long winded way to say let's make yyyy-mm legal in references. Stepho talk 01:16, 31 May 2020 (UTC)
- I support this, in particular because the only form with which this could be confused with (abbreviated year ranges), is simply not needed in the various
|date=
parameters in citations, because they specify specific dates, not date ranges. The only real-life exception that comes to my mind right now is conferences, which are typically given by their date range, but specific to the start and end days. Where would we have a need to specify a citation-related date as a year range? Perhaps, if the publication history is unclear and the publication can be narrowed down only to a vague year range. But that would be an extremely rare use compared to the much more frequent desire to specify a date in the "yyyy-mm" format in citations. Also, there would certainly be no valid reasons why, in these rare cases, such year ranges would have to be given in abbreviated form. The only other occurence of abbreviated year ranges in citations could be in the|title=
, but there it could not be in conflict with "yyyy-mm" dates in|date=
parameters. - Therefore, I propose a slight change of the MOS to also allow the "yyyy-mm" form in citations (in addition to the "yyyy-mm-dd" form, which is already allowed there), and at the same time disallow or at least further deprecate abbreviated year ranges there (only there, and only the abbreviated form). (A possible usage in
|title=
would remain unaffected by this change both ways, as we simply have to use whatever is used in the source there.) - Realistically, this would have virtually no practical implications or downsides for users of abbreviated year ranges, simply because this form isn't in any frequent use in citations (so it would require only marginal cleanup of existing citations, if any at all). However, it would be a significant improvement in consistency and convenience whereever the "yyyy-mm-dd" format is already used in citations (very often).
- Another possible solution to the problem would be to at least allow (as parameter input in citation templates) the form "yyyy-mm-uu" or "yyyy-mm-XX" (to indicate unspecified days as defined as part of EDTFs per the new 2019 revision of ISO 8601 to give dates). As this would look ugly on surface, this form should be allowed only on source code level, and the citation templates should convert it to either "yyyy-mm" or "Month yyyy" for display purposes. This would at least settle the issue of how to consistently and reliably specify such dates on source code level.
- --Matthiaspaul (talk) 10:10, 19 July 2020 (UTC)
- Trappist the monk: Just FYI, since you keep track of what people want in the CS1 templates. WhatamIdoing (talk) 23:21, 8 August 2020 (UTC)
- I support this, in particular because the only form with which this could be confused with (abbreviated year ranges), is simply not needed in the various
- That's a long winded way to say let's make yyyy-mm legal in references. Stepho talk 01:16, 31 May 2020 (UTC)
How to cite announcement letters
What is the proper way to cite an announcement letter and how should the letter number, if any, be given? Some of those letters are available only on dead trees, and even when an announcement letter has been scanned, {{cite web}} doesn't seem appropriate. Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:53, 24 May 2020 (UTC)
- @Chatul: what sort of announcement letters do you mean? Missing cat? Engagement? In any case, most material before 50 years ago was on dead trees or dead animals (vellum) so there wouldn't be a URL anyway. Maybe there is an example you can use from C18 political pamphlets? It might be argued that, if it has never been formally captured, does it satisfy WP:NOTABLE and WP:RS, even WP:SELF. --John Maynard Friedman (talk) 13:43, 27 May 2020 (UTC)
- My use case is hardware and software announcement letters from IBM. Other vendors issued similar announcement letters for their products. My question was prompted by
{{cite web| title = IBM OS/390 Version 2 Release 5 Availability and Release 6 | id = 298-049 | date = February 24, 1998 | url = https://www.ibm.com/common/ssi/rep_ca/9/897/ENUS298-049/index.html | quote = UNIX System Services | publisher = IBM | work = Software Announcement}}
}}[1] in MVS; given the text "Announcement Letter Number: 298-049", it's also not clear whether to use the bare number in id= or something likeid=# 298-049
orid=Letter 298-049
.
- My use case is hardware and software announcement letters from IBM. Other vendors issued similar announcement letters for their products. My question was prompted by
- Are you saying that I shouldn't present, e.g., the URL http://bitsavers.org/pdf/ge/GE-6xx/CPB-1002_GECOS_Jul64.pdf, because the original document was printed on dead trees?
- WP:NOTABLE says "On Wikipedia, notability is a test used by editors to decide whether a given topic warrants its own article."; it says nothing about the sources cited being notable, and it's fairly common to see editors add {{cn}} asking for sources for, e.g., product announcement dates.
- WP:RS says either in traditional printed format or online, so it is perfectly legitimate to use a source first published on paper. In such cases, any URL given in the {{cite}} would refer to a scanned copy at, e.g., bitsavers. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:13, 27 May 2020 (UTC)
- Looks like we were at cross purposes. I thought you meant a personal letter, which I guess we would only cite if it were one of the Collected Letters of someone very notable.
- I thought I was agreeing with you that the medium is unimportant, what matters is the message; that a url is a nice-to-have but is certainly not essential or thousands of years of documents, scrolls, papyri etc would be banned - unlikely!
- Maybe I was stretching the notability rule but to have cited WP:TRIVIA might have been seen (with some justification) as confrontational.
- The IBM example is more like a bulletin. I can't see you have much alternative to using the full {{citation}} template and choosing the arguments that are relevant: {{cite book}} might be a good model (or maybe {{cite magazine}}, which has numbers?). I agree that {{cite web}} would not be appropriate given that many are not going to be digitised. You need a generic model that will stand with or without a web page.
- But now that we know what you have in mind, perhaps there are more experienced editors who can advise? --John Maynard Friedman (talk)
- Template:Cite document feels appropriate (it redirects to {{cite journal}}). Template:Cite letter is probably not going to work for you. Depending upon the situation, Template:Cite press release might be interesting, too. WhatamIdoing (talk) 23:23, 8 August 2020 (UTC)
- WP:RS says either in traditional printed format or online, so it is perfectly legitimate to use a source first published on paper. In such cases, any URL given in the {{cite}} would refer to a scanned copy at, e.g., bitsavers. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:13, 27 May 2020 (UTC)
References
- ^ "IBM OS/390 Version 2 Release 5 Availability and Release 6". Software Announcement. IBM. February 24, 1998. 298-049.
UNIX System Services
Plain text vs templates
It says overleaf at WP:CITE#To be avoided: adding citation templates to an article that already uses a consistent system without templates, …
This seems overly restrictive to me in some cases. Many articles use plain text short citations with an extensive list of sources. Starting from a citation in the article, readers will have difficulties finding the source and then returning to their previous position in the text. Consistent use of citation templates can aid that navigation. Applying those templates will not change the presentation of the citations, apart from adding clickable links – which is the point. Other benefits of these templates are that they 1) detect misspellings between citations and sources; 2) identify short citations without source; 3) identify uncited sources. I understand that some editors object to using these templates because they feel they are too complicated. I understand that, but I don't understand the objection when other editors do that work. I suggest to rephrase the cited part of the guideline to allow adding citation templates if they only add navigational aids and not change the citation style itself. Suggestion:
- In "To be avoided": adding citation templates which change the citation style to an article that already uses a consistent system
without templates, … - In "Generally considered helpful": improving existing citations by adding missing information, such as by replacing bare URLs with full bibliographic citations: an improvement because it aids verifiability, and fights linkrot; adding citation templates consistent with the existing citation style: an improvement because it adds navigational functionality and improves the correctness of the citation system;
I think these modifications would help to improve articles and make them more consistent (many articles use such templates already). -- Michael Bednarek (talk) 07:39, 8 August 2020 (UTC)
- Support per nom. This already happens, using wp:REFILL. I have done many many citation (re)formats and never had it questioned. Is this stating the obvious? --John Maynard Friedman (talk) 09:10, 8 August 2020 (UTC)
- And when I see you doing it, I don't "question", I revert it. I don't suppose you watchlist your drive-bys, & so don't notice. Depending on the circumstances, this is a gross breach of WP:CITEVAR. Johnbod (talk) 23:51, 8 August 2020 (UTC)
- If you really want this to happen, make it a real WP:RFC because, you know, this is WP:CITEVAR you're talking about. The benefits that you tout (misspelling, short-cites without target, etc) were the topic of discussion at WP:AN when error messages that make those benefits visible were turned on. Error messaging has since been turned off so only a few dedicated gnomes are fixing these errors. Anyone wanting to help should see the documentation at Category:Harv and Sfn template errors.—Trappist the monk (talk) 14:36, 8 August 2020 (UTC)
- I stopped reading when I came to the untrue claim "Applying those templates will not change the presentation of the citations". Jc3s5h (talk) 14:53, 8 August 2020 (UTC)
- If the goal is to mandate the use of templates, you can count me out. When citation templates were introduced, I tried to use them... and quickly became so confused that I went back to manually formatted html style. I understand that my reaction is not common (most editors do find templates easier to use), but it is real nevertheless. If we mandated templates, I would not be able to contribute to WP.
- Note... I have no problem when other editors follow up after I have edited, and convert my edits to some other preferred format/style. I do have a problem when others insist that I use their preferred format/style from the start (because I cannot).
- That said... I do think we over-stress the need for consistency. I have worked on several articles where the various editors used whatever citation format/style they were comfortable with - resulting in a mixed, inconsistent styling ... and you know what? That lack of consistency was not a big problem. Yes, consistency is nice... but it isn’t necessary. Blueboar (talk) 16:24, 8 August 2020 (UTC)
- Opposed. WP:CITEVAR has been a guideline for years. This proposer is free to add such templates to articles he creates, but there are many editors who prefer not to use them. There is no reason to impose their use on everyone. Such a change in policy may well drive away many productive contributors. --Robert.Allen (talk) 19:13, 8 August 2020 (UTC)
- Being dogmatic about something is never a good idea. Forcing other editors to avoid the usage of citation templates is also likely driving contributors away, so the argument works bothways. The underlying argument, however, is that, everyone prefers the style s/he is used to.
- IMHO, every editor should be allowed to contribute in the way s/he can and feels comfortable with. However, if an editor not using citation templates stops contributing to an article for a reasonable time (some weeks or months), other editors willing to contribute should be allowed to convert raw text citations to use citation templates without prior discussion. Citation templates significantly improve the functionality in many ways, I wonder how all these advantages can be ignored by some (fortunately only very few) editors. --Matthiaspaul (talk) 14:38, 9 August 2020 (UTC)
- Oppose. Changing to templates can be an improvement, but there can be good reasons not to do so and it requires consensus per WP:CITEVAR. I don't see a good reason to allow non-consensus mass format changes. —David Eppstein (talk) 19:21, 8 August 2020 (UTC)
- Michael Bednarek, it might not be obvious, but the current rule is that you can change to Wikipedia:Citation templates after a discussion. You're effectively proposing that discussions be considered optional, and, e.g., the preferences of the regular editors at that specific article can be over-ridden without notice or consideration by anyone who just happens to feel like it. That's probably not a good idea. WhatamIdoing (talk) 23:30, 8 August 2020 (UTC)
- Strong Oppose per the various arguments of opposers above. Johnbod (talk) 23:49, 8 August 2020 (UTC)
- One by one:
- User:Trappist the monk: Instead of immediatley launching an RfC, I wanted to test the waters. I know this is WP:CITEVAR – we are writing on its talk page. I'm not concerned with the error messages you mention; I'm referring to spelling mistakes in authors names or publication years. As plain text, they remain undetected. Using templates will show them.
- User:Jc3s5h: How does using templates to generate clickable links change the appearance of an article's text?
- User:Blueboar: Of course I don't advocate the mandatory use of templates, and my proposed text doesn't suggest that. I propose a less rigid version of this guideline.
- User:Robert.Allen: I'm not proposing to impose the use of citation templates; I'm proposing to loosen their prohibition in certain cases. That WP:CITEVAR has been a guideline for years shouldn't preclude discussion about its development and improvement.
- User:David Eppstein: I can't see how a plain text short citation can ever be an improvement over a linked one. Consensus? That's why I'm here.
- User:WhatamIdoing: You describe my proposal correctly, up to a point. I suggest that the original citation format be kept, only that it may be enhanced by templates.
- Noone has presented any arguments why plain text short citations are better than linked ones. It's unimaginable if the same would apply to inline or list-defined full citations; [17] without a link? Aren't the #benefits 1) to 3) improvements? -- Michael Bednarek (talk) 11:54, 9 August 2020 (UTC)
- One by one:
Michael Bednarek asked "How does using templates to generate clickable links change the appearance of an article's text?" BUT THAT IS NOT WHAT BEDNAREK WROTE IN THE PROPOSAL Bednarek wrote "Applying those templates will not change the presentation of the citations, apart from adding clickable links".
To see how the proposal would "change the presentation of the citations" consider an example citation before and after.
Before: The global positioning system emerged in the 1970s. (Ghilani, 2018, p. 323)
Bibliography
After: The global positioning system emerged in the 1970s.[1]
References
- ^ Ghilani, Charles D. (2018). Elementary Surveying (15th ed.). New York: Pearson. p. 323.
— Preceding unsigned comment added by Jc3s5h (talk • contribs) 14:26, 9 August 2020 (UTC)
- That's not the kind of modification I suggest. Sticking with parenthetical citations you used (although I'm more concerned with
<ref>...</ref>
-style citations):
- That's not the kind of modification I suggest. Sticking with parenthetical citations you used (although I'm more concerned with
Before After The global positioning system emerged in the 1970s (Ghilani, 2018, p. 323). The global positioning system emerged in the 1970s (Ghilani 2018, p. 323). Bibliography (unchanged) - Ghilani, C. D. (2018). Elementary Surveying. New York: Pearson.
- Using
<ref>...</ref>
-style citations:
- Using
Before After Text that is supported by a citation.[1] References
- ^ Miller 2001, p. 123
Text that is supported by a citation.[1] References
- ^ Miller 2001, p. 123.
Sources - Miller, John (2001). Authoritave on the Subject. London: University Press.
- Hope this helps. -- Michael Bednarek (talk) 07:55, 10 August 2020 (UTC)
- User:Michael Bednarek, we may be talking about different things. You seem to be assuming that the article already uses {{cite book}}, and you want permission to impose {{sfn}} on the article without bothering to ask the regular editors about it. I'm talking about "an article that already uses a consistent system without templates" Your alleged benefit of detecting a typo in the author's names by comparing the contents of the {{sfn}} and {{cite book}} templates against each other will not exist in that situation, because there are no citation templates to match the sfn fields against.
- As a practical matter, if you're just testing the waters, you might want to wait until User:CaptainEek's proposal at Wikipedia:Village pump (proposals)#Deprecate parenthetical citations (which would semi-sorta ban some plain-text short cites) is resolved first. While you're waiting, you can be thinking about a good way to explain why it's too burdensome for the fans of the sfn template to start a talk page discussion before imposing that (fairly unpopular) template, but still necessary and appropriate for anyone who wants to remove that template to follow CITEVAR's discussion process. WhatamIdoing (talk) 15:45, 9 August 2020 (UTC)
- Also: If you want to change what the wikitext looks like in the editing window from "no template" to "use template", that constitutes "a change in citation formatting" as far as CITEVAR is concerned, even if there is absolutely no visible difference to the reader. WhatamIdoing (talk) 16:00, 9 August 2020 (UTC)
- Nowhere in your proposal do you say that it is here to
test the waters
. Do not blame me for not knowing your mind. - There are only a few ways that editors can determine if there are
spelling mistakes in authors names or publication years
. These ways are:- manually test each short-cite link to its matching long citation
- use one of the several personal java-scripts to detect
CITEREF
anchor / link errors - enable display of harv/sfn error messaging using personal css
- The manual testing clearly doesn't work. If it did, there would not be as many pages listed in Category:Harv and Sfn no-target errors as there are.
- The second method isn't really working because, according to
{{NUMBEROFACTIVEUSERS}}
there are 119,004 active users. Of those, according to Wikipedia:User scripts/Most imported scripts, there are five 'HarvErrors' scripts in use by a total of 181+39+29+1+2 = 252 active users. - The third method isn't really working because, according to this cirrus search, there are less than 20 editors who have added the necessary selector to their personal css.
- So yes, with regard to
spelling mistakes in authors names or publication years
,[as] plain text, they remain undetected.
But, the belief that simply[using] templates will show them
is not true. - —Trappist the monk (talk) 22:05, 9 August 2020 (UTC)
- My mistake. I thought that Notarget 2005 would produce an error for everyone. FWIW, I think it should. -- Michael Bednarek (talk) 07:55, 10 August 2020 (UTC)
- User:Michael Bednarek: I do not find templates like "sfn" and "harvbn" objectionable. It is the requirement to use a limited number of templates, like "cite book", as the target in the bibliographic section. If there were a template that could label the target without forcing a particular citation format, I would not object to the the use of "sfn" and "harvbn". So, for instance, maybe a plain text bibliographic citation could be started with a label, something like: {{bref|author|year}}, followed by the full citation in plain text. The "bref" template would add no text of its own but include in the target of "sfn" or "harvnb" all the text that followed up to the next line break. It would create the links to the bibliographic citation and the pop-ups. The text that followed could include other templates, such as "ISBN", "Ill", or even "cite book" or "cite web", etc. This would give editors a lot of freedom in formatting the bibliographic citation. Perhaps something like this already exists. If so, I am unaware of it. --Robert.Allen (talk) 17:05, 12 August 2020 (UTC)
{{wikicite}}
?- —Trappist the monk (talk) 17:09, 12 August 2020 (UTC)
- Thanks for the information. I should try it out. If this works, I would suggest mentioning the alternatives that can be used as targets of "sfn" and "harvnb" etc in the documentation of those templates. --Robert.Allen (talk) 17:24, 12 August 2020 (UTC)
- Umm,
{{wikicite}}
is mentioned at the (shared) doc page for{{sfn}}
and the various{{harv}}
family templates ... - —Trappist the monk (talk) 17:33, 12 August 2020 (UTC)
- Sorry, the documentation is rather lengthy, and somehow I overlooked it. I tried the "Wikicite" template, but one must add a lot of text (e.g., parameter names, etc) and a nested template ("SfnRef") to the bibliographic citation to get it to work:{{Wikicite|ref={{SfnRef|Last name of author(s)|Year}} |reference=...}}. (It took me a while to even figure this out.) Maybe it is not possible for such a template to include text following of the final braces. I don't know, but I feel like perhaps it could be simplified and parallel to "sfn" and "harvnb", like I suggested above ("{{bref|author|year}}..."). Also, it would be more general and could be used with any other citation template without having add the "ref={{SfnRef|Last name of author(s)|Year}}" parameter to any of those. --Robert.Allen (talk) 18:31, 12 August 2020 (UTC)
- I guess I don't understand the problem then. If I write:
{{wikicite|ref={{sfnref|Green|2020}}|reference=<Green's citation details>}}
- I can copy the
{{sfnref}}
template from that to be used as the basis for any number of{{sfn}}
templates that link to the{{wikicite}}
template (use{{harvid}}
if{{harv}}
templates are preferred).{{wikicite}}
encloses the whole so that the plain-text citation does not become separated from its anchor ID. Using{{sfnref}}
inwikicite
allows MediaWiki to provide the pale blue highlight when hovering the mouse-pointer over the short-form citation: {{harvnb|Green|2020}}
→ Green 2020- <Green's citation details>
- It is generally impossible for templates to see anything outside of their bounding
{{
and}}
. It is possible to create an anchor ID ahead of some plain text (pale blue highlighting not available):{{anchor|<ID>}}
<plain-text citation>
- If you want that to be linked from a short-form template you have a couple of options:
- set
<ID>
using{{sfnref|<namelist>|<year>}}
{{harvnb|Green|1990}}
→ Green 1990{{anchor|{{sfnref|Green|2020}}}}
→ <Green's 1990 citation details>
- set
<ID>
manuallyCITEREF<namelist><year>
{{harvnb|Green|1991}}
→ Green 1991{{anchor|CITEREFGreen1991}}}}
→ <Green's 1991 citation details>
- set
<ID>
to<identifier name>
and set|ref=<identifier name>
in the short form template to match{{harvnb|Green|1992|ref=anchorID}}
→ Green 1992{{anchor|anchorID}}}}
→ <Green's 1992 citation details>
- set
- Alas, there is no You Know What I Want button.
- —Trappist the monk (talk) 19:34, 12 August 2020 (UTC)
- I guess I don't understand the problem then. If I write:
- Sorry, the documentation is rather lengthy, and somehow I overlooked it. I tried the "Wikicite" template, but one must add a lot of text (e.g., parameter names, etc) and a nested template ("SfnRef") to the bibliographic citation to get it to work:{{Wikicite|ref={{SfnRef|Last name of author(s)|Year}} |reference=...}}. (It took me a while to even figure this out.) Maybe it is not possible for such a template to include text following of the final braces. I don't know, but I feel like perhaps it could be simplified and parallel to "sfn" and "harvnb", like I suggested above ("{{bref|author|year}}..."). Also, it would be more general and could be used with any other citation template without having add the "ref={{SfnRef|Last name of author(s)|Year}}" parameter to any of those. --Robert.Allen (talk) 18:31, 12 August 2020 (UTC)
- Umm,
- Thanks for the information. I should try it out. If this works, I would suggest mentioning the alternatives that can be used as targets of "sfn" and "harvnb" etc in the documentation of those templates. --Robert.Allen (talk) 17:24, 12 August 2020 (UTC)
- Thanks for all the help. I went ahead and added "Wikicite", "sfn", and "harvnb" templates to an article I created, Hôtel de Crozat, which caused almost no changes to the citation style of the article, yet added the links to the citations and the popups, so I am happy with the results. Still, I think it is a bit complicated for most editors, but I would not object to these kinds of changes. --Robert.Allen (talk) 19:53, 12 August 2020 (UTC)
Citation style
An RfC which may, depending on its outcome, affect the content of this guideline, is currently held at WP:VPPRO#Deprecate parenthetical citations. Please comment there, not here. --Francis Schonken (talk) 14:15, 8 August 2020 (UTC)
- Updated my comment above, after the RfC's close. --Francis Schonken (talk) 12:37, 9 September 2020 (UTC)
- Now archived - the close is here. Johnbod (talk) 16:46, 15 September 2020 (UTC)
Querying closer of CITEVAR RfC on recent diff
Seraphimblade, this diff is in response to the RfC you just closed. Given that you mentioned that wording changes would need discussion on this talk page, do you regard the diff as inline with your close? Also pinging Biogeographist, the author of the diff. Mike Christie (talk - contribs - library) 20:01, 5 September 2020 (UTC)
- Although I am the author of the diff, the text that I inserted in Special:Permalink/976908526 § Parenthetical referencing was copied almost verbatim from Wikipedia:Parenthetical referencing where it had been inserted by Seraphimblade. Biogeographist (talk) 20:08, 5 September 2020 (UTC)
- Thanks for the clarification; I hadn't noticed that. Mike Christie (talk - contribs - library) 20:09, 5 September 2020 (UTC)
The edit was reverted by Nikkimaria. Is there an alternative proposal? Biogeographist (talk) 20:24, 5 September 2020 (UTC)
- There were a number of changes made in that edit, some of which I think are perfectly fine (eg removing "; the short citations may be given either as footnotes, or as parenthetical references within the text.") and others of which merit more careful discussion. Nikkimaria (talk) 20:31, 5 September 2020 (UTC)
- It looks like the discussion is already proceeding, as suggested, though of course there's no problem with taking an initial try at it as a starting point for such discussion. Nikkimaria, it might be helpful if you elaborated on which portions you object to and why. Seraphimblade Talk to me 21:12, 5 September 2020 (UTC)
- I've made these changes which I expect require no discussion, though of course others may disagree. I see an inconsistency between the PAREN and CITEVAR change proposed, and indeed between the actual discussion close and the PAREN change, with regards to how existing articles with parenthetical citations are to be treated. Nikkimaria (talk) 21:27, 5 September 2020 (UTC)
CITEVAR update after parenthetical citations RfC
- Addition to the paragraph after arbitration case quote: "However, as of 5 September 2020, parenthetical referencing is a deprecated citation style on English-language Wikipedia."
- Modification of the first bullet point of Wikipedia:Citing sources#To be avoided, currently reading: "[..., avoid:] * switching between major citation styles, e.g., parenthetical and <ref> tags, or replacing the preferred style of one academic discipline with another's;" – proposed replacement text: "[..., avoid:] * switching between major citation styles or replacing the preferred style of one academic discipline with another's – except when moving away from parenthetical referencing;"
- Add new bullet point to Wikipedia:Citing sources#Generally considered helpful: "* converting parenthetical referencing to an acceptable referencing style."
--Francis Schonken (talk) 07:14, 12 September 2020 (UTC)
- For clarity, "However, as of 5 September 2020, parenthetical referencing is a deprecated citation style on English-language Wikipedia" would be better as: "However, as of 5 September 2020, inline parenthetical referencing in article body text is a deprecated citation style on English-language Wikipedia". Note the change of "parenthetical referencing" to "inline parenthetical referencing in article body text" (if that is too long, "inline parenthetical referencing" would be acceptable). This change will help avoid the incorrect interpretation that use of the {{harv}} family of templates is deprecated within
<ref>...</ref>
tags. Use of the {{harv}} family of templates within<ref>...</ref>
tags (including within the {{efn}} family of templates) is an established kind of shortened footnotes, and is not deprecated; this is clear in the discussion close but is not always clear when using the term "parenthetical referencing" alone. Francis Schonken and I have been arguing about this at Wikipedia talk:Parenthetical referencing § Extent of deprecation. Biogeographist (talk) 15:17, 12 September 2020 (UTC)- I agree that it should be clear in the text that it is specifically inline parenthetical references that are deprecated. --Izno (talk) 16:28, 12 September 2020 (UTC)
- Correct. An example of an ambiguous use of the term "parenthetical referencing" that could be interpreted in various ways is the following quote, which Francis Schonken said at Wikipedia talk:Parenthetical referencing § Extent of deprecation:
Please appreciate that parenthetical referencing is deprecated. The entire guideline is deprecated: it should not be smuggled back in via references.
Here Francis Schonken's phrasesmuggled back in via references
could be taken to mean that the {{Harvard citation}} family of templates should no longer be used in footnotes, which is incorrect; they are still permitted in footnotes. In a discussion elsewhere it has been suggested to rename the {{Harvard citation}} family of templates to the {{Short citation}} family of templates to avoid confusion. - The deprecation discussion only deprecated inline parenthetical referencing. The first sentence of the proposal is:
I propose that we formally deprecate the inline parenthetical citation style.
And the closure summary is:This discussion has reached a consensus that inline parenthetical referencing should be deprecated.
The word "inline" is prominent in both places to avoid confusion. Biogeographist (talk) 17:03, 13 September 2020 (UTC)- Yes, though I think you'll find that the "inline" in the proposal was only added (in response to complaints) after the rfc was well underway. The proposal and discussion certainly failed to "avoid confusion" dramatically; the close has passed the parcel to this page to sort out the details. Johnbod (talk) 16:42, 15 September 2020 (UTC)
- I agree that there was dramatic confusion during the discussion due to the initial ambiguity in the proposal, but the "inline" that was then added to the proposal and included in the closing statement eliminated that particular ambiguity: I have only seen one editor (mentioned in my previous comment) suggest after the close that non-inline parenthetical references were also deprecated by the RfC. Biogeographist (talk) 19:58, 15 September 2020 (UTC)
- Yes, though I think you'll find that the "inline" in the proposal was only added (in response to complaints) after the rfc was well underway. The proposal and discussion certainly failed to "avoid confusion" dramatically; the close has passed the parcel to this page to sort out the details. Johnbod (talk) 16:42, 15 September 2020 (UTC)
- Correct. An example of an ambiguous use of the term "parenthetical referencing" that could be interpreted in various ways is the following quote, which Francis Schonken said at Wikipedia talk:Parenthetical referencing § Extent of deprecation:
- I agree that it should be clear in the text that it is specifically inline parenthetical references that are deprecated. --Izno (talk) 16:28, 12 September 2020 (UTC)
- Given that there is not a single acceptable referencing style, I think it would be more appropriate to encourage discussion rather than drive-by changes. Nikkimaria (talk) 15:58, 12 September 2020 (UTC)
- ... Which would have been status quo re CITEVAR, which is what the RFC rejected. --Izno (talk) 16:12, 12 September 2020 (UTC)
- Under CITEVAR prior to the RfC, such a discussion could come to the conclusion that inline parenthetical referencing is the most appropriate style; that's not what I'm suggesting. What we want to avoid is edit-warring in the case that Editor X wants to change an article to sfn and Editor Y thinks the existing cites should just be wrapped in ref tags, or prefers any of the myriad other acceptable replacement styles. Nikkimaria (talk) 18:18, 12 September 2020 (UTC)
- OK, I see your concern. My issue with what you originally wrote is that CITEVAR also includes:
Editors should not attempt to change an article's established citation style ... without first seeking consensus for the change.
which is also now untrue for inline parenthetical citations. For articles where it is already established, I think I'd tend toward a WP:BRD cycle with something "the change away from inline parentheticals can be made boldly and should not be reverted -- further changes should be discussed". I realize that gives first mover advantage, but the distinction between wrapping and sfn et al is not what I would call significant. (And it's not like we don't already have a first mover advantage built in to CITEVAR.) All that said, I am unsure whether that is something that needs to be in the guideline directly; perhaps a note for it for the transition period. --Izno (talk) 18:28, 12 September 2020 (UTC)- Saying the change made boldly cannot be reverted is very much not in line with BRD. Given that there are very very few articles using parenthetical refs, and that there are multiple potentially acceptable replacements, and that there is no deadline to getting this changed, I guess I'm not seeing a strong rationale why we can't ask people to discuss first. Nikkimaria (talk) 18:41, 12 September 2020 (UTC)
- The discussion should be about which style to change it to, not whether to change it. I'd say to simply put the inline references in ref-tags as default, were a discussion to ensue, and afterwards change everything to the agreed-upon new style. The WP:BRD could come in if someone chooses a style on their own, and then get reverted; a discussion would start with the once-inline refs put into ref-tags as the status quo. El Millo (talk) 18:49, 12 September 2020 (UTC)
- The point is that we've already had the discussion. If people see a reason to argue between using {{sfn}} and wrapping {{harv}}/{{harvtxt}} in ref tags, that should not stop the obvious improvement which is converting to a footnoted version. Otherwise, in your edit warring world, we'll see stonewalling because people will not allow the first action of making a footnoted version of the article. Either be pessimistic or not. :) --Izno (talk) 14:44, 13 September 2020 (UTC)
- That's why I suggested above to just put the inline parenthetical references in ref-tags were a discussion to start. You boldly change the citation style, someone doesn't like it and reverts it, so you just put the inline refs in ref-tags as default and start a discussion to decide the citation style to go with. El Millo (talk) 18:13, 13 September 2020 (UTC)
- Saying the change made boldly cannot be reverted is very much not in line with BRD. Given that there are very very few articles using parenthetical refs, and that there are multiple potentially acceptable replacements, and that there is no deadline to getting this changed, I guess I'm not seeing a strong rationale why we can't ask people to discuss first. Nikkimaria (talk) 18:41, 12 September 2020 (UTC)
- OK, I see your concern. My issue with what you originally wrote is that CITEVAR also includes:
- Under CITEVAR prior to the RfC, such a discussion could come to the conclusion that inline parenthetical referencing is the most appropriate style; that's not what I'm suggesting. What we want to avoid is edit-warring in the case that Editor X wants to change an article to sfn and Editor Y thinks the existing cites should just be wrapped in ref tags, or prefers any of the myriad other acceptable replacement styles. Nikkimaria (talk) 18:18, 12 September 2020 (UTC)
- I wouldn't make this more complicated or problematic than it actually is. Let's consider two cases for an editor doing a conversion (away from the parenthetical referencing style):
- First case: the editor who does the conversion is the "first major contributor" (per the WP:CITEVAR terminology): in that case "the style used by the first major contributor" is reset to the non-parenthetical referencing style that editor chooses.
- Second case: the editor who does the conversion is not the "first major contributor" (whether drive-by or a major contributor different from the first): also this editor can choose whatever referencing style they think best, that is, apart from incoherent, and, of course, also apart from a different flavour of the parenthetical referencing style. Consecutive editors either agree with the thus established coherent non-parenthetical style or they don't: in the case they don't, and they happen to be the "first major contributor" they can't revert to the deprecated style, but they can convert to a style which they think more appropriate, which then becomes "the style used by the first major contributor" (see first case). Otherwise, if they disagree with the newly established style, while not being the first major contributor, they can't change the style established by the converting editor (citing from the CITEVAR guidance: "If the article you are editing is already using a particular citation style, you should follow it") without finding consensus on the talk page first.
- Prior discussion, before conversion, is not obligatory, as said above (it was not among the options accepted by the closer of the RfC). Nonetheless, whoever wants to initiate a conversion and wants to consult fellow-editors on what style to convert to is of course free to start a discussion regarding that topic on the article's talk page prior to conversion. Also, my OP proposal of this subsection did not modify any wording already present in the CITEVAR guidance inviting to discussion: I simply don't think that the conversions mandated by the RfC are an exceptional case in that respect. --Francis Schonken (talk) 10:51, 15 September 2020 (UTC)
- the close does not say that "Prior discussion, before conversion, is not obligatory" at all - it leaves it to this page to sort out that sort of thing. We could, and probably should, say that anyone ready to change the style should propose this first, saying what they want to change it to. If there is no opposition to this they can go ahead. Johnbod (talk) 16:51, 15 September 2020 (UTC)
- The relevant passage of the close seems to be: "At existing articles, discussion of how best to convert parenthetical citations into currently accepted formats should be held if there is objection to a particular method" (my emphasis). It does not say "At existing articles, discussion of how best to convert parenthetical citations into currently accepted formats should be held prior to conversion". For clarity: the option was proposed, and discussed with some detail, in the RfC, but clearly had not nearly enough support to call it "consensus" – on the contrary, the opposing reasoning, that it would not change much to current guidance if preliminary talk page consensus were necessary for each individual convert, had a broad consensus throughout the RfC discussions (hence the wording of the close is a good summary of that). --Francis Schonken (talk) 05:51, 16 September 2020 (UTC)
- Exactly! And how do we discover if there is objection to a particular method? By the person intending to make the changes first asking on talk. Johnbod (talk) 15:46, 16 September 2020 (UTC)
- No, talk page first as an obligation was explicitly rejected in the concluded RfC. It is also unnecessary (and contraproductive) as a method to establish "objection": the usual, & inherently Wikipedia-like, method to establish objection being: see what happens after a WP:BOLD edit. The conversion needs to be done, per the decided deprecation. The work of whoever does the job is appreciated, and if they care about the article, which will usually be the case, they won't choose an inane method. Ergo, new Harvard-referencing-free citation style established: work from there (within the CITEVAR framework, and keeping to the consensus on the deprecation) if you have objections. Mandatory prior discussion is more prone to stalling the conversion, will make it less likely anyone can be found to do the actual conversion (especially if the talk page discussion would turn into a hornet's nest, while prone to be a covert discussion about whether the parenthetical referencing style would not better be kept, etc). So no, it is clear from the RfC discussion, and its close, that this is not the way we want to go. Just do the count of those who commented on the topic in the closed RfC, and suppose that you held a separate RfC precisely on this topic, with the same people turning up, with the same opinions: do you think there would be more than a WP:SNOW chance the consensus would be different this time? But let that not stop you from proceeding with an RfC on that topic if you think it might render a different result with others turning up, or people having changed opinion (note that I did: half-way through the RfC I proposed a middle way for conversion implementations... which subsequently received zero traction... leading to me no longer supporting that middle way, and supporting the consensus on that point wholeheartedly). So, please, proceed with an RfC if you think it has a reasonable chance, but until if and when such RfC results in a different consensus, there is no need to change a clear outcome of an RfC when we're deciding how to update CITEVAR. --Francis Schonken (talk) 16:40, 16 September 2020 (UTC)
- I'm completely failing to see where "talk page first as an obligation was explicitly rejected in the concluded RfC". Perhaps you could point to where you think this is said. Johnbod (talk) 14:34, 18 September 2020 (UTC)
- No, talk page first as an obligation was explicitly rejected in the concluded RfC. It is also unnecessary (and contraproductive) as a method to establish "objection": the usual, & inherently Wikipedia-like, method to establish objection being: see what happens after a WP:BOLD edit. The conversion needs to be done, per the decided deprecation. The work of whoever does the job is appreciated, and if they care about the article, which will usually be the case, they won't choose an inane method. Ergo, new Harvard-referencing-free citation style established: work from there (within the CITEVAR framework, and keeping to the consensus on the deprecation) if you have objections. Mandatory prior discussion is more prone to stalling the conversion, will make it less likely anyone can be found to do the actual conversion (especially if the talk page discussion would turn into a hornet's nest, while prone to be a covert discussion about whether the parenthetical referencing style would not better be kept, etc). So no, it is clear from the RfC discussion, and its close, that this is not the way we want to go. Just do the count of those who commented on the topic in the closed RfC, and suppose that you held a separate RfC precisely on this topic, with the same people turning up, with the same opinions: do you think there would be more than a WP:SNOW chance the consensus would be different this time? But let that not stop you from proceeding with an RfC on that topic if you think it might render a different result with others turning up, or people having changed opinion (note that I did: half-way through the RfC I proposed a middle way for conversion implementations... which subsequently received zero traction... leading to me no longer supporting that middle way, and supporting the consensus on that point wholeheartedly). So, please, proceed with an RfC if you think it has a reasonable chance, but until if and when such RfC results in a different consensus, there is no need to change a clear outcome of an RfC when we're deciding how to update CITEVAR. --Francis Schonken (talk) 16:40, 16 September 2020 (UTC)
- Exactly! And how do we discover if there is objection to a particular method? By the person intending to make the changes first asking on talk. Johnbod (talk) 15:46, 16 September 2020 (UTC)
- The relevant passage of the close seems to be: "At existing articles, discussion of how best to convert parenthetical citations into currently accepted formats should be held if there is objection to a particular method" (my emphasis). It does not say "At existing articles, discussion of how best to convert parenthetical citations into currently accepted formats should be held prior to conversion". For clarity: the option was proposed, and discussed with some detail, in the RfC, but clearly had not nearly enough support to call it "consensus" – on the contrary, the opposing reasoning, that it would not change much to current guidance if preliminary talk page consensus were necessary for each individual convert, had a broad consensus throughout the RfC discussions (hence the wording of the close is a good summary of that). --Francis Schonken (talk) 05:51, 16 September 2020 (UTC)
- "Consensus to not implement" and "no consensus to implement" are not exactly the same thing – but for the discussion here that makes no difference: a positive "consensus to implement" on what you propose ("... anyone ready to change the style should propose this first ...") would be needed: such consensus can not be derived from the RfC, and even less from the implementation discussion here, thus far. So, as I said, feel free to initiate an auxiliary RfC on this point (as recommended in the RfC close). If you'd read the closed RfC in its entirety, you'd see such new RfC would unlikely result in accepting your proposal. I've summarized what I think is the gist of the RfC on this point: other than that, there's no shortcut to actually reading the RfC and come to your own summary regarding its gist on this topic. As long as there's no consensus otherwise, I go by the currently established "consensus to not implement" or "no consensus to implement" (whatever flavour of the same difference you prefer) on this point. --Francis Schonken (talk) 09:52, 21 September 2020 (UTC)
- Oddly enough (since I made several comments there) I have read the whole rfc, more than once, and I don't agree with your interpretation, either of that or the close, at all. Hardly any of those commenting addressed this point or anything like it. I take it you are abandoning your claim that "talk page first as an obligation was explicitly rejected in the concluded RfC". You should consider the end of the close. Johnbod (talk) 14:59, 21 September 2020 (UTC)
- Which doesn't help your stance in any way: as said already more than once, a successful subsidiary RfC would be needed to claim consensus on what you propose, and without consensus this should not go into the guidance. Whether success would be likely or unlikely for such RfC I will not speculate any further: I was clear about what I think about its chances. --Francis Schonken (talk) 15:13, 21 September 2020 (UTC)
- We have just had a hugely long rfc. The very well-considered close on that made it clear that the detailed implementation of that, namely how the changes should be done, belonged on this page. There is absolutely no need for another Rfc to confirm that! We should propose and agree procedures here; if there is deadlock in doing that another Rfc might possibly be needed, but claiming that everything that doesn't agree with your personal opinion is either a) ruled out by the Rfc close, or b) needs another Rfc, is deeply unhelpful. Johnbod (talk) 17:02, 21 September 2020 (UTC)
- @Johnbod: The last point of the close explicitly says it:
At existing articles, discussion of how best to convert parenthetical citations into currently accepted formats should be held if there is objection to a particular method.
(my underlining) A discussion should be held if there's an objection to the new method implemented. That clearly sets the course of actions: boldly implement a change, if reverted for a reason other than WP:IDONTLIKEIT, discuss and arrive at a consensus. Anyone can start a discussion before implementing a change if they want, but that's not required. El Millo (talk) 17:39, 21 September 2020 (UTC)- "Discussion should take place at relevant policy pages, especially WT:CITE, to decide on changes to wording, and if need be followup requests for comment may be initiated. Those discussions should focus on how, not whether, the wording changes should be made, as the latter decision has already been made here." That's explicit. The bit you are quoting is anything but. People cannot be expected to watch every article in time to revert before there are any further edits. User:Seraphimblade (sorry to bother) - there are claims above that your close explicitly rules out requiring a notification/discussion on article talk before an article is converted. Perhaps you can comment as to whether that was the meaning you intended? Johnbod (talk) 20:23, 21 September 2020 (UTC)
- @Johnbod: The last point of the close explicitly says it:
- We have just had a hugely long rfc. The very well-considered close on that made it clear that the detailed implementation of that, namely how the changes should be done, belonged on this page. There is absolutely no need for another Rfc to confirm that! We should propose and agree procedures here; if there is deadlock in doing that another Rfc might possibly be needed, but claiming that everything that doesn't agree with your personal opinion is either a) ruled out by the Rfc close, or b) needs another Rfc, is deeply unhelpful. Johnbod (talk) 17:02, 21 September 2020 (UTC)
- Which doesn't help your stance in any way: as said already more than once, a successful subsidiary RfC would be needed to claim consensus on what you propose, and without consensus this should not go into the guidance. Whether success would be likely or unlikely for such RfC I will not speculate any further: I was clear about what I think about its chances. --Francis Schonken (talk) 15:13, 21 September 2020 (UTC)
- Oddly enough (since I made several comments there) I have read the whole rfc, more than once, and I don't agree with your interpretation, either of that or the close, at all. Hardly any of those commenting addressed this point or anything like it. I take it you are abandoning your claim that "talk page first as an obligation was explicitly rejected in the concluded RfC". You should consider the end of the close. Johnbod (talk) 14:59, 21 September 2020 (UTC)
- the close does not say that "Prior discussion, before conversion, is not obligatory" at all - it leaves it to this page to sort out that sort of thing. We could, and probably should, say that anyone ready to change the style should propose this first, saying what they want to change it to. If there is no opposition to this they can go ahead. Johnbod (talk) 16:51, 15 September 2020 (UTC)
- I don't think "first major contributor" is a status that is attached to an editor for life. I think that status only lasts until there is a consensus to change to a different style, or the style chosen becomes technically infeasible due to a software change. At that point, the status of "first major contributor" is permanently extinguished. Jc3s5h (talk) 13:57, 15 September 2020 (UTC)
- Anyway, for all articles using the parenthetical referencing system there is consensus to change to a different style, a consensus which was established by the RfC. The "technically infeasible" case does not apply to what follows from the parenthetical referencing RfC, so I don't consider that any further at this point. Modifications mandated to the CITEVAR guidance by the parenthetical referencing RfC do *not* include a modification of the prerogatives of the "first major contributor" as accorded by the CITEVAR guidance, so that part of the guidance should not be touched. The RfC outcome should not be used to throw the CITEVAR guidance upside-down on points not covered by the RfC outcome (if you think that prerogatives of the first major contributor should be limited in time, then you can start a separate discussion and/or RfC on that, but that is unrelated to the updates mandated by the parenthetical referencing RfC). The parenthetical referencing RfC does not say to which referencing system a former parenthetical referencing system should be converted in an article. So it is natural that the first major contributor (if such editor is still around) can choose to which system the conversion goes, until a consensus establishes differently. If such editor is no longer around for an article, or doesn't want to get engaged, then there is no problem either, per the steps I described above. --Francis Schonken (talk) 14:30, 15 September 2020 (UTC)
- ... Which would have been status quo re CITEVAR, which is what the RFC rejected. --Izno (talk) 16:12, 12 September 2020 (UTC)
- I am not certain that we need to call this out directly in CITEVAR; the other two bullets are reasonable. I might prefer to see a note in the context of the other two bullets rather than the callout earlier. --Izno (talk) 16:28, 12 September 2020 (UTC)
- In re to the first bullet should that be added, I do not endorse adding timestamps directly in the text. Footnotes are generally sufficient if we want to point to an exacting RFC or similar, if we believe that is necessary here. (I'm willing to entertain that it is given the scope of change.) --Izno (talk) 16:33, 12 September 2020 (UTC)
- Since I was pinged here, I'll try to clarify: WP:CITEVAR is not a valid reason to oppose a change away from inline parenthetical citations. CITEVAR prohibits making such a change unless a consensus exists that the change should be made. That consensus discussion has been held and has come to a consensus that inline parenthetical citations should be changed, so there is already a consensus that the change ought to be made. As in the close, the discussion should be over how, not whether, the change should be made away from inline parenthetical references. The "whether" is already decided, so CITEVAR has already been satisfied. Seraphimblade Talk to me 20:49, 21 September 2020 (UTC)
- User:Seraphimblade (sorry to bother again), thanks for the prompt reply, but that wasn't the question at all. It is about the process - "how" not "whether", as you say. It was claimed above that your close explicitly ruled out requiring a notification on an article's talk giving the proposed new citation style, before the changes are made. I don't see that, "explicitly" or even implicitly, in your close. Is it there, or not? As I'm sure you know, this page has long included (since an Arbcom ruling in 2006) : "Editors should not attempt to change an article's established citation style merely on the grounds of personal preference, to make it match other articles, or without first seeking consensus for the change." It seems therefore well within the scope of this page to have requirements as to notification/consultation on the new style to replace inline parentheticals at the article level. Johnbod (talk) 21:00, 21 September 2020 (UTC)
- It would not be mandatory to seek further consensus for such a change, as the consensus to change away from it already exists. If someone objects to the way a change is done, then a discussion should be held as to the best way to carry it out. Seraphimblade Talk to me 23:56, 21 September 2020 (UTC)
- Seraphimblade So you have to catch them immediately after the change (no doubt to sfn) and before any any further edits, and the changes vanishing from watchlists? Johnbod (talk) 00:16, 22 September 2020 (UTC)
- I am not sure who you are trying to "catch". If you see a change you don't think was done well and you think it should be done differently, open a discussion about it on the talk page. That can be done five seconds or five years after the change was made. Seraphimblade Talk to me 00:26, 22 September 2020 (UTC)
- Ok, then I'll explain. If you had over 30,000 articles on your watchlist, as I do, you'd know that there are already many drive-by cite-warriors continually going round converting articles not already in sfn, but some other style (very rarely inline parenthetical) to that, usually neglecting to mention this in edit summaries, and often doing it in a sloppy or brutal way, causing all sorts of problems, of the kinds some people mentioned in the rfc. These are illegal changes under the CITEVAR passage just quoted, and if spotted at the time and reverted, they generally just move on. But if it is not spotted at once, once other changes are made once, restoring their changes becomes a huge job (especially if you don't use automated tools), and often their illegal changes stick. Johnbod (talk) 00:47, 22 September 2020 (UTC)
- @Johnbod:
- Maybe drop the stick and back slowly away from the horse carcass? I mean, you've got now at least four editors, including the RfC closer, who say that what you proposed regarding "talk page first" is not going to happen (at least not in the short run, and not with the current RfC result) – maybe think about everybody's time usage (including your own) and end the time sink?
- Re. "... sfn ..." – if you don't like sfn, then I suggest you get going and convert as many Harvard referencing articles as you can to an acceptable referencing style that is neither parenthetical nor sfn, instead of wasting time here. I have no prejudice for or against sfn: when I was the first to introduce an in-line reference in an article that was sometimes sfn, but also often one of the other acceptable styles, that is, whatever I thought would work best for the article I was editing (e.g. "Aus der Tiefen rufe ich, Herr, zu dir", an article I initiated: currently 7 references, not a single sfn). I have a few 10000 articles on my watchlist, but those that I remembered as articles where I was bothered by the parenthetical referencing style were already converted by me, a few of these to harvnb's between ref tags. All of these conversions without major issues. So I suggest you get started without delay, lest someone else converts an article before you to a style you don't like. That's the advantage of the system resulting from the RfC (at least, as clarified above by the RfC's closer): it invites to rather actually do the conversions than to discuss about it on talk pages without actually getting rid of the parenthetical referencing.
- --Francis Schonken (talk) 06:34, 23 September 2020 (UTC)
- My position here is entirely defensive - cite-bandits keep making illegal changes to articles, converting them to sfn. I have absolutely no interest in converting any citation styles myself, in any direction; I have better things to do. I think I'll keep holding the stick, not least because I get thanks for many edits on this topic. Johnbod (talk) 12:09, 23 September 2020 (UTC)
- @Johnbod:
- Ok, then I'll explain. If you had over 30,000 articles on your watchlist, as I do, you'd know that there are already many drive-by cite-warriors continually going round converting articles not already in sfn, but some other style (very rarely inline parenthetical) to that, usually neglecting to mention this in edit summaries, and often doing it in a sloppy or brutal way, causing all sorts of problems, of the kinds some people mentioned in the rfc. These are illegal changes under the CITEVAR passage just quoted, and if spotted at the time and reverted, they generally just move on. But if it is not spotted at once, once other changes are made once, restoring their changes becomes a huge job (especially if you don't use automated tools), and often their illegal changes stick. Johnbod (talk) 00:47, 22 September 2020 (UTC)
- It's not that strict. It's just like any other change: the bold-revert-discuss cycle. The objections would have to come soon-ish after the change, not years after, but immediately after is a bit much. El Millo (talk) 00:28, 22 September 2020 (UTC)
- He said 5 years. But, as explained above, this will very often not be practical. Johnbod (talk) 00:47, 22 September 2020 (UTC)
- Re. "It's just like any other change: the bold-revert-discuss cycle" – no, it isn't: if someone converts an article from the parenthetical referencing style to an acceptable non-deprecated referencing style then the article can not be reverted to the deprecated style, neither before nor after a local discussion. That's the RfC outcome. Let's compare to what is already codified in CITEVAR: "imposing one style on an article with inconsistent citation styles" is "Generally considered helpful" – also in this case, if an editor comes along and converts an inconsistent referencing style to a consistent one, CITEVAR protects that consistent style, and "reverting" to an inconsistent style before or after discussion is not allowed. If someone doesn't agree with the consistent style (and would like another), they'd have to go to the article's talk page for a discussion first (that is: without reverting), and seek consensus on another consistent style before modifying the referencing style of that article in mainspace. I think that is a scheme that works well for parenthetical referencing too, and this is what seems to be engrained in the RfC outcome. That is to say, after the RfC closer's clarifications above, such scheme is what is without doubt engrained in the RfC's close. --Francis Schonken (talk) 06:34, 23 September 2020 (UTC)
- I'm sorry. What I meant to say is that the logic behind contesting the change would be similar to it in terms of strictness, answering Johnbod's comment about
hav[ing] to catch them immediately after the change ... and before any any further edits
. Of course the "revert" part wouldn't be allowed in these cases. El Millo (talk) 07:21, 23 September 2020 (UTC)- Tx. With that clarification having been given, are we OK with implementing what I proposed in the OP of this subsection (except that the date of deprecation will be put in a footnote, avoiding to put "timestamps directly in the text" per Izno's suggestion above)? --Francis Schonken (talk) 07:52, 23 September 2020 (UTC)
- I support it. El Millo (talk) 08:47, 23 September 2020 (UTC)
- Certainly not - for a start, the proposed text just says "parenthetical referencing", which as the rfc amply demonstrated is highly ambiguous. It needs to say "inline parenthetical referencing", and then spell out (perhaps in a note), exactly what is meant by that, with an example. There are other issues too. Johnbod (talk) 12:14, 23 September 2020 (UTC)
- I agree. The deprecation of inline-references surrounded by parentheses ({{harv}}) from the close of the RFC is much more specific, does not include parenthetical referencing in footnotes, and does not include situations that use Harvard style to refer to sources as part of the prose text of the article rather than purely as a marker for a source ({{harvtxt}}). Any change to this guideline needs to take equal care. —David Eppstein (talk) 16:57, 23 September 2020 (UTC)
- I've added "inline" to the notice on the page. See Talk:Lesbian#Parenthetical_referencing for an example of how experienced editors are already being led astray by this omission, claiming the rfc as justification for removing templated refs. Johnbod (talk) 15:40, 26 September 2020 (UTC)
- I agree. The deprecation of inline-references surrounded by parentheses ({{harv}}) from the close of the RFC is much more specific, does not include parenthetical referencing in footnotes, and does not include situations that use Harvard style to refer to sources as part of the prose text of the article rather than purely as a marker for a source ({{harvtxt}}). Any change to this guideline needs to take equal care. —David Eppstein (talk) 16:57, 23 September 2020 (UTC)
- Tx. With that clarification having been given, are we OK with implementing what I proposed in the OP of this subsection (except that the date of deprecation will be put in a footnote, avoiding to put "timestamps directly in the text" per Izno's suggestion above)? --Francis Schonken (talk) 07:52, 23 September 2020 (UTC)
- I'm sorry. What I meant to say is that the logic behind contesting the change would be similar to it in terms of strictness, answering Johnbod's comment about
- I am not sure who you are trying to "catch". If you see a change you don't think was done well and you think it should be done differently, open a discussion about it on the talk page. That can be done five seconds or five years after the change was made. Seraphimblade Talk to me 00:26, 22 September 2020 (UTC)
- Seraphimblade So you have to catch them immediately after the change (no doubt to sfn) and before any any further edits, and the changes vanishing from watchlists? Johnbod (talk) 00:16, 22 September 2020 (UTC)
Explanatory footnotes with references
- See also Wikipedia talk:Parenthetical referencing#Parenthetical referencing in explanatory footnotes where this was previously discussed.
There is some confusion on whether or not an explanatory footnote, which usually consists of some prose, which may or may not be followed by a reference. Here's a text that appears in an explanatory footnote (see previous discussion where I got this example):
The question of whether all psychotherapies are all roughly equally effective (known as the Dodo bird verdict) and the question of whether all effective psychotherapies share common factors (known as common factors theory) are two different questions: "Though many authors view outcome equivalence as the main reason to study common factors in psychotherapy, we cheerfully disagree. Regardless of outcome, it is noncontroversial to say that psychotherapies of many origins share several features of process and content, and it follows that better understanding the patterns of these commonalities may be an important part of better understanding the effects of psychotherapies. That is, irrespective of whether some psychotherapies are equivalent to others in symptomatic outcome, understanding what part of clients' improvement is due to factors that are shared by several approaches appears to us to be a conceptually and clinically important question." (McAleavey & Castonguay 2015, p. 294 )
My clear stance is that whether or not such prose appears in a footnote, its referencing is inline to the prose, and parenthetical as a style. So, this can, imho, clearly be converted to a non-parenthetical acceptable style, per the RfC outcome. Thoughts?
I'll be posting an invitation to continue the discussion about this topic here, at the end of the previous discussion (which seems to have petered out without coming to a conclusion). --Francis Schonken (talk) 16:48, 26 September 2020 (UTC)
- Disagree. If the text is already in a footnote, then by definition any reference accompanying it is already in a footnote, regardless of how that reference may be styled. Nikkimaria (talk) 16:50, 26 September 2020 (UTC)
- What would be the point of converting such citations? The aim of the recent deprecation of parenthetical references was to get citations out of the text and into footnotes, so they don't clutter the article prose. But here the citations is already in a footnote, so the issue is moot. Converting to a system of nested footnotes has obvious disadvantages: it makes for awkward navigation (readers will have to navigate not just between the footnotes and the bibliography items linked there, but also between the footnotes, the footnotes to those footnotes, and the bibliography entries that may be linked in either), and it's got accessibility issues (footnotes are typically displayed in a smaller font size, which will make the superscript link to the reference even smaller – see MOS:SMALL). – Uanfala (talk) 17:18, 26 September 2020 (UTC)
- Strongly disagree. The consensus of the recent RFC was only to convert IN-TEXT parenthetical referencing. Short footnotes containing parenthetical referencing were clearly and explicitly allowed to continue. Longer footnotes containing both parenthetical referencing and an explanation of the context of the reference may be a bit of a gray area, but there is clearly no prior consensus for removing these, and no good reason for doing so other than WP:POINTy following of made-up rules. Additionally, there are strong technical reasons for keeping them as is: footnotes within (normal) footnotes don't work, so it would generally not be possible to convert these to footnote style. —David Eppstein (talk) 17:36, 26 September 2020 (UTC)
- The RfC was about Harvard refs in article text, not in footnotes. It's going too far not to let people use them in footnotes, e.g. "As Smith (2010, p. 3) makes clear ...". SarahSV (talk) 18:01, 26 September 2020 (UTC)
- Re. "As Smith (2010, p. 3) makes clear ..." – that is an example of in-text attribution, see Wikipedia:Citing sources#In-text attribution for guidance. In-text attribution is allowed in every part of an article (lead section, body, footnotes—whether explanatory or references—, image captions etc). As such it is unrelated to the discussion in this subsection: an in-text attribution is not even a reference: in-text attributions need to be accompanied by references ("..., in addition to an inline citation after the sentence" per the WP:INTEXT guidance), which was the rule as well before as after the RfC, and was in no way modified by the RfC. Please avoid adding to the confusion by irrelevant examples. --Francis Schonken (talk) 06:04, 27 September 2020 (UTC)
- Francis Schonken said that "Smith (2010, p. 3)"
is not even a reference
. If there is a full citation in the reference list with an author named Smith and a publication date of 2010, then "Smith (2010, p. 3)" is a (short) reference/citation. That's what {{Harvard citation text}}, one of the Harvard short citation templates, is for, and one might choose to use it in explanatory footnotes. Francis Schonken also saidsee Wikipedia:Citing sources § In-text attribution for guidance
, but that section does not mention short references/citations of the form "Smith (2010, p. 3)"; instead, it focuses on less-precise in-text attribution that does not use such a short citation. Biogeographist (talk) 13:19, 27 September 2020 (UTC)
- Francis Schonken said that "Smith (2010, p. 3)"
- Re. "As Smith (2010, p. 3) makes clear ..." – that is an example of in-text attribution, see Wikipedia:Citing sources#In-text attribution for guidance. In-text attribution is allowed in every part of an article (lead section, body, footnotes—whether explanatory or references—, image captions etc). As such it is unrelated to the discussion in this subsection: an in-text attribution is not even a reference: in-text attributions need to be accompanied by references ("..., in addition to an inline citation after the sentence" per the WP:INTEXT guidance), which was the rule as well before as after the RfC, and was in no way modified by the RfC. Please avoid adding to the confusion by irrelevant examples. --Francis Schonken (talk) 06:04, 27 September 2020 (UTC)
- Disagree, like all the other responses above. As I already noted at Wikipedia talk:Parenthetical referencing § Parenthetical referencing in explanatory footnotes, converting such a parenthetical reference in a footnote to another footnote (resulting in footnotes-to-footnotes) is an option but has disadvantages, therefore it requires weighing advantages and disadvantages in a given case. Biogeographist (talk) 23:44, 26 September 2020 (UTC)
- Disagree, as the others. These were hardly, if at all, mentioned in the rfc comments, & not at all in the close. Johnbod (talk) 02:51, 27 September 2020 (UTC)
- Re. "... hardly, if at all, mentioned in the rfc comments" – indeed, I wouldn't have brought this up if it had been clear from the RfC (hence, I said "My ... stance is ...", and not, "... follows from the RfC" or some such expression). The RfC outcome says "... if need be followup requests for comment may be initiated": I suppose this is a case where such follow-up RfC would be best to clarify the matter. --Francis Schonken (talk) 06:04, 27 September 2020 (UTC)
- The close at WP:PARREF says: "This discussion supports the deprecation only of parenthetical style citations directly inlined into articles. It does not deprecate the use of the entire citation format when it is used within <ref></ref> tags, nor the use of the {{sfn}} and {{harv}} templates." It is clear to me that this conclusion permits parenthetical short citations in footnotes, but if it wasn't clear to Francis Schonken, the preceding comments should have helped clarify it. Biogeographist (talk) 13:19, 27 September 2020 (UTC)
- Re. "... hardly, if at all, mentioned in the rfc comments" – indeed, I wouldn't have brought this up if it had been clear from the RfC (hence, I said "My ... stance is ...", and not, "... follows from the RfC" or some such expression). The RfC outcome says "... if need be followup requests for comment may be initiated": I suppose this is a case where such follow-up RfC would be best to clarify the matter. --Francis Schonken (talk) 06:04, 27 September 2020 (UTC)
- Explanatory footnotes are allowed. Explanatory footnotes may need to refer to works listed in the bibliography. Nested <ref> tags are not allowed. Therefore inline citations using plain English—Smith in her 1985 article— or parenthetical citations—Doe (2003, p5) disagrees, instead claiming—are a structural necessity.† Such usage could be enhanced with templates from the harv template family if compatible with the citation style in use in the article.
- † An exception would be articles that do not use <ref> tags, such as articles that simply put a number in parentheses after the passage that is supported by a citation, and provide a numbered list of references. Jc3s5h (talk) 14:24, 27 September 2020 (UTC)
- While <ref> tags don't work within <ref> tags, they do work within {{#tag|ref... coding - which has the desired effects (and also helps to separate the explanatory notes from the regular references.Nigel Ish (talk) 15:23, 27 September 2020 (UTC)
- I never heard of {{#tag|ref. Where is this documented? Is the documentation any place an editor is likely to find it? Jc3s5h (talk) 15:52, 27 September 2020 (UTC)
- Nigel Ish may have been referring to {{refn}}? An example of {{sfn}} within {{refn}} is given at Help:Shortened footnotes § Separate explanatory notes with shortened footnotes and their references. Biogeographist (talk) 16:03, 27 September 2020 (UTC)
- #tag is how Template:efn functioned before Lua conversion (and under the hood even Lua still uses the same PHP implementation). See mw:Help:Magic words#Miscellaneous. --Izno (talk) 17:25, 27 September 2020 (UTC)
- An example in use is the article HMS TB 23 (1907) - Wikipedia does have a problem in that there are so many ways of doing the same thing with generally rubbish documentation - we shouldn't really have systems that work that aren't properly documented. Then again, we shouldn't have endless arguments about Angels dancing on pinheads to try to implement a very simple change - i.e. don't use in-text referencing.Nigel Ish (talk) 19:02, 27 September 2020 (UTC)
- {{refn}} with refs nested inside it orders the nested ref footnote before the refn footnote, not the best ordering. More signifiantly, refn with nested refs does not work for citation styles that pull all the references to the end with {{reflist|refs=...}} syntax. It doesn't give any error message when you try it, and the footnote markers for the nested refs show up, but the nested refs do not appear in the list of footnotes. So, my conclusion is that it's a hacky and obscure non-fix for a non-problem (because parenthetical references within footnotes are not a problem), with too many edge cases to use reliably. —David Eppstein (talk) 20:22, 27 September 2020 (UTC)
- The first of which is why I usually prefer efn if it's actually necessary to put refs together like that. The LDR issue is a known issue in Phabricator but seems to be accordingly low on priority given the scarcity of that referencing method. Yes, I agree that it's a little hackish--and I think that's also a 'known' issue. Heh. --Izno (talk) 15:07, 28 September 2020 (UTC)
- I never heard of {{#tag|ref. Where is this documented? Is the documentation any place an editor is likely to find it? Jc3s5h (talk) 15:52, 27 September 2020 (UTC)
- While <ref> tags don't work within <ref> tags, they do work within {{#tag|ref... coding - which has the desired effects (and also helps to separate the explanatory notes from the regular references.Nigel Ish (talk) 15:23, 27 September 2020 (UTC)
How to do citations
Khah Language is one the major language of Ramban district .my request is to create a separate page for khah language I do not know how to edit citations
Shakeel Rahi Sohilpori (talk) 12:09, 25 August 2020 (UTC)
- I have replied at User talk:Shakeel Rahi Sohilpori.-- Toddy1 (talk) 13:11, 25 August 2020 (UTC)
Citing multiple sections of the same source
The article currently has a WP:Citing sources#Citing multiple pages of the same source section. However, it provides no guidance on citing multiple sections and section URLs from the same source. Absent templates for handling it automatically, I believe that there should be guidance here and in Footnotes. Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:55, 9 August 2020 (UTC)
- Perhaps this and this follow-up - recent discussions at FAC talk would help - I think it represents the usual community view. It is made harder by the templates people insist on using. Johnbod (talk) 03:25, 9 August 2020 (UTC)
- The easiest way by far is to separate the citation from the reference. Gather all your citations in alphabetical order in a "Citations" section, then use {{sfn}} to reference the citation and relevant page numbers. See §2.4.2, first example. Martin of Sheffield (talk) 10:09, 9 August 2020 (UTC)
- text<ref name=oper/><ref>Taken from {{cite manual
- | title = 5000-21005A
- | section = Program Descriptor
- | page = 4-2
- }}
- </ref> text<ref>Taken from {{cite manual
- | title = 5000-21005A
- | section = Data Descriptor
- | page = 4-3
- }}
- </ref> text<ref>Taken from {{cite manual
- | title = 5000-21005A
- | section = Data and Input/Output
- | pages = 4-4 – 4-13
- }}
- </ref> text<ref>Taken from {{cite manual
- | title = 5000-21005A
- | section = External Result Descriptors
- | pages = 4-14 – 4-15
- }}
- </ref>
- to handle it, but that's unsatisfactory for several reasons. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:47, 9 August 2020 (UTC)
References
- ^ The Operational Characteristic of the Processors for the Burroughs B 5000 (A ed.), Detroit: Burroughs, 5000-21005A
- ^ Taken from "Program Descriptor". 5000-21005A. p. 4-2.
- ^ Taken from "Data Descriptor". 5000-21005A. p. 4-3.
- ^ Taken from "Data and Input/Output". 5000-21005A. pp. 4-4–4-13.
- ^ Taken from "External Result Descriptors". 5000-21005A. pp. 4-14–4-15.
- Unless one is dealing with an edited book, where different chapters are written by different authors, I don't think it's typical to cite a page range and some other indication of where the cite is within the book, such as a chapter or section title. If you really needed to you could
|at=
. For example, if I wanted to cite all of a chapter plus another page, I could writeat = Chapter 7, , inside front cover
. Jc3s5h (talk) 15:20, 9 August 2020 (UTC)- I'd echo what Jc3s5h said, but also direct you to Template:Sfn#Default_mode: "- |loc= – in-source location ... may be used to supplement |p= and |pp=; information such as a section or figure number". Martin of Sheffield (talk) 15:31, 9 August 2020 (UTC)
- @Chatul: Have you looked into Template:Harvc? Might possibly be of some use. Umimmak (talk) 15:32, 9 August 2020 (UTC)
- Chatul, if you're unhappy about having so many little blue clicky numbers at the end of the sentence, then WP:CITEBUNDLE might help. WhatamIdoing (talk) 15:56, 9 August 2020 (UTC)
- I condensed my example too much; the citations are in different places. I've edited the example to make that clear. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:10, 9 August 2020 (UTC)
- That's exactly what I thought the problem was - as I said above "It is made harder by the templates people insist on using." Abandon them & it all becomes much easier. Johnbod (talk) 16:36, 9 August 2020 (UTC)
- Contrary to what Jc3s5h says, it is helpful to readers for short citations to cite both page numbers (so people with that exact reference can go directly to the appropriate part of the reference) and a section title, theorem number, or other structural name for what part of the text is being cited (so people who have a version of the reference with different pagination can still find it). If our citation templates are discouraging that style, then that is a problem with the templates. But as Johnbod suggests, it may be easier just not to use the templates for some things. —David Eppstein (talk) 17:15, 9 August 2020 (UTC)
- I guess when I ran into that issue, I didn't bother with the templates. XOR'easter (talk) 06:44, 10 August 2020 (UTC)
- It is harder for me to use straight text then to use the templates. I was asking that this page address the stylistic issues, not just the mechanics of getting a certain appearance. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:10, 9 August 2020 (UTC)
- Contrary to what Jc3s5h says, it is helpful to readers for short citations to cite both page numbers (so people with that exact reference can go directly to the appropriate part of the reference) and a section title, theorem number, or other structural name for what part of the text is being cited (so people who have a version of the reference with different pagination can still find it). If our citation templates are discouraging that style, then that is a problem with the templates. But as Johnbod suggests, it may be easier just not to use the templates for some things. —David Eppstein (talk) 17:15, 9 August 2020 (UTC)
- I need to cite manuals that don't show authors, and I need to use a style consistent with existing citations, which are mostly {{cite book}}, {{cite manual}}, {{cite web}} and {{citation}}. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:10, 9 August 2020 (UTC)
- Chatul, if you're unhappy about having so many little blue clicky numbers at the end of the sentence, then WP:CITEBUNDLE might help. WhatamIdoing (talk) 15:56, 9 August 2020 (UTC)
- Citations
- The Operational Characteristic of the Processors for the Burroughs B 5000 (A ed.), Detroit: Burroughs, 5000-21005A Martin of Sheffield (talk) 22:40, 9 August 2020 (UTC)
- Citations
- (edit conflict)
- I was just thinking along similar lines:
- 5000-21005A, p. 4-2, Program Descriptor
- 5000-21005A, p. 4-3, Data Descriptor
- 5000-21005A, pp. 4-4–4-13, Data and Input/Output
- 5000-21005A, pp. 4-14–4-15, External Result Descriptors
- 5000-21005A. Publisher. 1957.
- —Trappist the monk (talk) 22:49, 9 August 2020 (UTC)
- @Trappist the monk:There is an {{ec}} template in the last update by User:Trappist the monk; is there a way to locate the lost update?
- There currently is no External References section, just a References section with a
{{Reflist|ref=}}
. Are you proposing that I change the style of all of the existing citations? The proposal by User:Martin of Sheffield would seem to allow a smaller change. In either case, I'd still like to see some style guidelines for cases like this. Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:53, 10 August 2020 (UTC)- I experienced an edit conflict with Editor Martin of Sheffield. I don't think that anything was lost but made the announcement as a just-in-case. I made no mention of §External references nor am I suggesting that you change the style of all existing citations because dragons dwell there. I don't know why you think I did because in this discussion, only you have used the words 'external references' until I have parroted them back at you. I was not as willing to dig as Editor Martin of Sheffield; I took what was visible in this discussion and used that information to cobble up my example. My example is more-or-less the same as Editor Martin of Sheffield's; they differ only in the details. Only in your 12:03, 10 August 2020 (UTC) post do we learn the article to which this discussion applies. Without you state that from the start, I'm not likely try to noodle it out. So, as a courtesy to other editors in future discussions, supplying the article name and explicit examples from that article will benefit you because the quality of answers you get will likely be better.
- —Trappist the monk (talk) 14:42, 10 August 2020 (UTC)
- You didn't use the words but you did show the citations as a bulleted list, which is certainly a change in citation style. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:36, 10 August 2020 (UTC)
You're now moving into another region. Have a read of WP:CITEREF, specifically "Editors should not attempt to change an article's established citation style merely on the grounds of personal preference, to make it match other articles, or without first seeking consensus for the change." If you need to do the references this way, then that is good grounds for seeking consensus for change. Make the proposal on the article's talk page. It might be helpful to let us know which page you are working on. Martin of Sheffield (talk) 08:25, 10 August 2020 (UTC)
- That quote is precisely why I prefer your suggestion to that of Trappist the monk, although in this specific case all of the citations are mine. The article in question is Burroughs large systems descriptors.
- What about that {{ec}} in Trappist the monk's last edit? Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:03, 10 August 2020 (UTC)
- Right, solely because all the citations so far are yours. and from a common source I'd stick my neck out slightly and say it is reasonable in this case to change the format before it becomes established. I'm even prepared to do the legwork for you if you want. It would be nice though if the cited manual could be filled out a bit; when does it date from, are there any named authors, is it available online? Martin of Sheffield (talk) 19:41, 10 August 2020 (UTC)
- I found a copy at bitsavers and updated the citation. Like most hardware manuals I've seen, there are no listed authors. I couldn't find a publication date so I used the copyright date. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:11, 17 August 2020 (UTC)
- In reverse order: it's sensible to assume the copyright date is the publication date. The author field is slightly more problematical. Old-school Brits (like me) tend to be happy with corporate authors whereas young Yanks religiously delete them (young Brits, old Yanks, and all others take sides as a appropriate). In the days of card indexes you had to have an author, the index was arranged that way and half a dozen drawers of "Anon" helped no-one. In the present case I would use
|author=Burroughs Corporation
. "You pays your money and you takes your choice"! Martin of Sheffield (talk) 15:11, 17 August 2020 (UTC)
- In reverse order: it's sensible to assume the copyright date is the publication date. The author field is slightly more problematical. Old-school Brits (like me) tend to be happy with corporate authors whereas young Yanks religiously delete them (young Brits, old Yanks, and all others take sides as a appropriate). In the days of card indexes you had to have an author, the index was arranged that way and half a dozen drawers of "Anon" helped no-one. In the present case I would use
- I found a copy at bitsavers and updated the citation. Like most hardware manuals I've seen, there are no listed authors. I couldn't find a publication date so I used the copyright date. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:11, 17 August 2020 (UTC)
How to reference online information that can't be given a URL
I am looking to add information to a certain article. I have found a reference online, but viewing the information requires having an account on the website. The issue is, if a reader follows the URL in order to get to the reference, it redirects them to the login page. If they choose to make an account, the login page redirects to the website's homepage. As a result, there is no URL that I can put in the ref tag, since the actual URL ultimately redirects to the wrong page. Additionally, the information requires navigating through a menu on the page, and the results from navigating through the menu are not reflected in the URL. So, if I add the URL to the page as a reference, I would have to also list instructions for how to get to the particular results. None of this is ideal. What is the accepted convention for dealing with this? --PuzzledvegetableIs it teatime already? 17:02, 21 August 2020 (UTC)
- If they have an account and are logged on, will the URL take them to the correct page? If so, I would link to the destination page and use an appropriate
|xxxxxxx-access=
paramater (e.g.|url-access=
) to indicate a logon would be required. See Template:Cite_web#Subscription_or_registration_required - If not, is there a title of the article that makes it clear what they should search for? That, in conjunction with one of the
access
parameters, may be sufficient, too. TJRC (talk) 17:53, 21 August 2020 (UTC)
- What’s the specific website? It also might provide some guidance for how to cite it, which might be a useful starting off point for Wikipedia. Umimmak (talk) 01:13, 22 August 2020 (UTC)
- Puzzledvegetable, One thing that's worth considering is if the service where you found the source has some kind of unique id which you can cite. Even if it's not one of the well-known IDs such as doi, JSTOR, OCLC, etc, you can just shove it into the generic "id" field. As an example, in Lynching of Wilbur Little, I cited something that's on Proquest, behind their paywall, and put "ProQuest document ID 493381239" in the "id" field. Somebody with a Proquest account should be able to search for that directly. -- RoySmith (talk) 03:22, 22 August 2020 (UTC)
Proposed change regarding ref tags before closing parenthesis (round bracket)
Please see: Wikipedia talk:Manual of Style#Ref tags before closing paren. This is a proposal to change citation placement practices, and may have implications for precision/accuracy of citations. — SMcCandlish ☏ ¢ 😼 21:07, 24 August 2020 (UTC)
Any tools for finding duplicate citations?
[I have edited this comment so the instructions remain optimal. The operator of the Extractor Web page added option "Only Display duplicate URL addresses" on my suggestion; I have added it here, added it to the Project page at WP:DUPREF, and deleted my suggestion to use the "uniq" tool. 26 Aug 20]
Are there any tools to help in finding duplicate citations in an existing article? I have looked for such a tool to use within Wikipedia, without success (a comment below says that WP:AWB will deduplicate citations). A reasonably simple non-Wikipedia method that works:
- Go to Web page URL Extractor For Web Pages and Text and paste the URL of the Wikipedia article into Step 1, Option 2 (or copy the article in Edit mode and paste it into Option 3).
- In Step 2, untick "Remove duplicate addresses", and tick "Only Display duplicate URL addresses"
- In Step 3 click "Extract"
The duplicated URLs in the article, (sorted unless you unticked "Sort" in Step 2) are in the output box.
You can then examine them, on the Web page or copied into a text editor. Note that displaying only duplicate addresses will not identify URLs which might have the same reference followed by different irrelevant parameters such as #ixzz2rBr3aO94 or ?utm_source=google&utm_medium=...&utm_term=...&utm_campaign=...., though most duplicate references are properly unique. Pol098 (talk) 15:20, 25 August 2020 (UTC)
- It's way easier to avoid the problem in the first place. Create a single alphabetical list of your citations then use either <ref>{{harvnb...}}</ref> or {{sfn}} which both do the same thing. Your reference list ({{reflist}}) then just has references and your citation list just the citations without duplication and the requirement to search half a dozen columns of random text for the full citation. Martin of Sheffield (talk) 15:28, 25 August 2020 (UTC)
- Is there any way to do this for an existing article (which is what I use this method for)? [I've added the clarification "in an existing article" to my original comment.] Pol098 (talk) 15:35, 25 August 2020 (UTC)
- Unfortunately for an existing article with existing citations you'll need to get consensus for a change. Unless the article is so disorganised that all accept you offer of help, getting consensus will take more time and effort than doing the job. Martin of Sheffield (talk) 15:42, 25 August 2020 (UTC)
- "you'll need to get consensus for a change" I think you're suggesting that changing all references in an existing page to Harvard form would then enable the page to be maintained without duplication, which seems a massive job (unless there are tools to do this?), which indeed would need consensus. All I want to do is, for a page with many "{{cite" citations, remove the duplicates; the only hard bit is identifying the duplicates. Pol098 (talk) 16:25, 25 August 2020 (UTC)
- Unfortunately for an existing article with existing citations you'll need to get consensus for a change. Unless the article is so disorganised that all accept you offer of help, getting consensus will take more time and effort than doing the job. Martin of Sheffield (talk) 15:42, 25 August 2020 (UTC)
- Is there any way to do this for an existing article (which is what I use this method for)? [I've added the clarification "in an existing article" to my original comment.] Pol098 (talk) 15:35, 25 August 2020 (UTC)
- WP:AWB will identify and (usually) correct exact duplicates in <ref> tags. --Izno (talk) 16:08, 25 August 2020 (UTC)
- Thanks. It might be worth adding this to the Project page, which is the first place I looked when seeking a tool. I added a link to this Talk section to the Project page at WP:DUPREF, as it said nothing about how to deduplicate. [28 Aug 20: I've removed the link to this Talk from the Project page, added instructions on URL Extractor, and mentioned AWB.] Pol098 (talk) 16:25, 25 August 2020 (UTC)
I have edited my first comment, which gives detailed instructions, following a "duplicates-only" option being added to the URL Extractor Web page. Pol098 (talk) 10:40, 26 August 2020 (UTC)
- I don't want to throw a damper on your work, but many citations will be to books for which there may be no URL, and often URLs are removed when there is a DOI. I hope this doesn't muck you about too much. Regards, Martin of Sheffield (talk) 10:45, 26 August 2020 (UTC)
- When a book has no URL, one can be created at OpenLibrary.org. Just saying. Nemo 10:57, 26 August 2020 (UTC)
- "many citations will be to books for which there may be no URL" So duplicates without a URL won't be found. Also, duplicates with different non-essential bits added to the URL won't be found. I have sometimes examined long lists of references trying to eyeball duplicates, which is slow and not easy. The technique I've described makes it a matter of seconds to find a lot of duplicates, not necessarily all - I find it useful, and am adding it to the Project page. Best wishes, Pol098 (talk) 11:08, 26 August 2020 (UTC)
- I still haven't found an appropriate Wikipedia tool; Extractor For Web Pages and Text remains what I find most useful. AWB (which I haven't used) would seem to be good for identical duplicates, but most duplicates are not identical (different order, last/first instead of author, different access-date, etc. etc.) Pol098 (talk) 14:45, 26 August 2020 (UTC)
- "many citations will be to books for which there may be no URL" So duplicates without a URL won't be found. Also, duplicates with different non-essential bits added to the URL won't be found. I have sometimes examined long lists of references trying to eyeball duplicates, which is slow and not easy. The technique I've described makes it a matter of seconds to find a lot of duplicates, not necessarily all - I find it useful, and am adding it to the Project page. Best wishes, Pol098 (talk) 11:08, 26 August 2020 (UTC)
- When a book has no URL, one can be created at OpenLibrary.org. Just saying. Nemo 10:57, 26 August 2020 (UTC)
As a test I ran the URL Extractor on a long article, did a little merging, and posted the rest of the list of apparent duplicates in the article's Talk page. An editor picked it up, found 5 of the 7 URLs listed were duplicates, and corrected them. Pol098 (talk) 11:41, 28 August 2020 (UTC)
- @Pol098: User:Zhaofeng Li/reFill merges exact matches, but User:Kaniivel/Reference Organizer is much more robust in finding duplicates. – Finnusertop (talk ⋅ contribs) 13:01, 16 September 2020 (UTC)
- @Finnusertop: My thanks for that, and it will be useful for others. I spent some time searching, unsuccessfully, for such a tool; I'd suggest adding it to the project page at WP:DUPREF, either in connection with the technique I propose, or replacing it. It would also be useful to add it to pages such as Wikipedia:Tools. I don't want to do this myself as I haven't yet used Reference Organizer, so won't know what I'm talking about. Possibly the URL Extractor will still have some use? Best wishes, Pol098 (talk) 14:18, 16 September 2020 (UTC) [Added later] I find that User:Kaniivel/Reference Organizer doesn't work for me, no better than scanning the list of references withut using any tool. I used the Reese Witherspoon article (at the time of this post), as actors and politicians tend to have long articles with duplicates. The URL Extractor found a single genuine duplicate URL (it also always shows two or a few more Wikipedia and Wikiquote URLs as duplicates, to be ignored). The Reference Organizer produced a long list of references that needed examining in detail; the two duplicated references were ticked as OK and allocated different ref names by the Organizer and not flagged in any way; they had the same URL and title, but archive-url and dates were different. So, for my purposes, the URL extractor was better, and the Organizer for this case at least, totally useless as a duplicate URL finder. Pol098 (talk) 15:39, 16 September 2020 (UTC)
The quality of web sources compared to offline sources.
Hello, I recently added the following caveat under the otherwise empty web citations section:
"Due to their tendency to be recent and self published, web pages are often of low quality."
First I'd like to ask, is there a place where web citations are discussed in more depth? Maybe this content would be more appropriate there.
Second, the edit was reversed, claiming the edit needed to be discussed. I think this is fair for such an influential and fundamental policy article.
Before delving into a discussion on the topic, is there anything I would need to know regarding the governance behind policy articles?
Thank you for your attention.--TZubiri (talk) 18:42, 31 August 2020 (UTC)
- A statement that web-page sources must still generally meet the publication requirements of WP:RS, and a pointer to WP:USERGENERATED, might be relevant. —David Eppstein (talk) 18:59, 31 August 2020 (UTC)
- The great majority of new peer-reviewed academic research appears first on the web and a steady trend is for it to appear only on the web. For this reason alone, it a bad idea to single out web pages for caution. I also don't see "recent" as an indicator of poor quality; in many fields (e.g., science) recent research tends to be more reliable than older research. Zerotalk 03:45, 1 September 2020 (UTC)
RFC regarding display of pages in cite journal
There is a request for comment proposing that the display of |pages=
in {{cite journal}}
be changed to match {{cite book}}
and other templates. Kanguole 13:25, 10 September 2020 (UTC)
RfC: Whether YouTube is a reliable source
YouTube allows uploading anything, and some possibility on one supporting oneself is here. -- PythonSwarm Talk | Contribs | Global 23:33, 10 September 2020 (UTC)
- See Wikipedia:Reliable_sources/Perennial sources#YouTube. —David Eppstein (talk) 00:07, 11 September 2020 (UTC)
- Youtube in a sense isn't really publisher itself but a distribution system or media "format". Hence the question whether it is a reliable source or not doesn't make much sense and is a bit like asking, whether a book, video cassette pr website is a reliable source. Instead you need to look athe publisher/author of an individual video (being available on Youtube). Now if the video is a legal copy and the publisher/author meets the requirement for reliable sources, then youtuve video is usually a reliable source otherwise it is not. However it is also worth to note that even in cases, where the reliability criteria is met, text sources are normally preferred to video sources (assuming both are available).--Kmhkmh (talk) 21:07, 12 September 2020 (UTC)
Nomination for deletion of Template:Use shortened footnotes
Template:Use shortened footnotes has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Bsherr (talk) 13:34, 16 September 2020 (UTC)
Relisting of discussion about Template:Use Harvard referencing
A WP:TFD discussion about Template:Use Harvard referencing has been relisted at Wikipedia:Templates for discussion/Log/2020 September 17 § Template:Use Harvard referencing. The relister said: The two big remaining questions then are "What should we do with the articles with deprecated citations?" and "What should we do with the articles with acceptable, footnoted, citations?"
If you are interested in the answers to those questions you may want to participate in the discussion. Biogeographist (talk) 23:12, 17 September 2020 (UTC)
Recommending ALA-LC romanization scheme for citations
Background Text in non-Latin writing systems is romanized. For example, when entering a citation using template:citation and related templates, the romanized title is entered in the title
parameter, while the optional original foreign title goes into script-title=
and recommended translation into trans-title=
, etc. (similarly, trans-chapter
and trans-work
). For example (from the article Kyiv):
- {{cite web
- | title=Chysel′nist′ naselenni͡a m.Kyi͡eva
- | script-title=uk:Чисельність населення м.Києва
- | trans-title= Population of Kyiv city
- | url=http://www.kiev.ukrstat.gov.ua/p.php3?c=527&lang=1 publisher= UkrStat.gov.ua | language=Ukrainian | date=1 November 2015 | accessdate=9 January 2016
- }}
This displays:
- "Chysel'nist' naselenni͡a m.Kyi͡eva" Чисельність населення м.Києва [Population of Kyiv city] (in Ukrainian). UkrStat.gov.ua. 1 November 2015. Retrieved 9 January 2016.
Wikipedia uses conventional wp:romanization systems for different languages. Some are international standards, and others are original-research wiki conventions.
English-language publishers and libraries worldwide now use the ALA-LC romanization standard for all bibliographies and library catalogues (the British Library adopted it in 1975). Many publishers also use it in simplified form for romanization in book copy.
Proposal this page and the MOS recommend using ALA-LC romanization in all citations (whether via template or not), for consistency with global English-language publishing and library sciences. This would make it easier and more consistent to enter citations from other sources, and to use our citations to find and verify our cited sources. This helps support wp:verifiability.
It would, in some cases, lead to different romanizations of words and names in our article text and in our citations. Minor in the above example, where the title would lose the diacritics: “Chyselnist naselennia m.Kyieva,” which corresponds to WP:UKR romanization. —Michael Z. 18:15, 28 September 2020 (UTC)
Citing documents in proprietary formats
Is it permissible to cite a document in a proprietary format, and what is the proper way to do so? The case that I am thinking of is in IBM BookManager format. Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:14, 29 September 2020 (UTC)
- Whether the format is proprietary is somewhat irrelevant, though it does decrease the likelihood that someone can read it (consider that MS Word file formats were proprietary for some time). What does matter is whether the document in question was published in a place where it can be accessed by company-outsiders. In a citation template, file formats can be specified in the badly named
|format=
, but only if you have a URL to go with it (it should be something like|url-file-format=
). --Izno (talk) 12:10, 29 September 2020 (UTC)- Do you mean something like this?[1]
|url-file-format=
isn't valid. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:17, 29 September 2020 (UTC)
- Do you mean something like this?[1]
- User:Chatul, your citation seems fine if you just omit the url-file-format parameter. I take Izno's comment to mean that
|format=
won't work if there is no URL, and that Izno doesn't think "format" is a wise name for the parameter; Izno thinks it would have been wiser to name it "url-file-format". Jc3s5h (talk) 20:58, 29 September 2020 (UTC)- Indeed.[2] --Izno (talk) 21:00, 29 September 2020 (UTC)
References
- ^ 3270 Information Display System Data Stream Programmer’s Reference (BookManager), IBM, GA23-0059-07
{{citation}}
: Unknown parameter|url-file-format=
ignored (help) - ^ 3270 Information Display System Data Stream Programmer’s Reference (BookManager), IBM, GA23-0059-07
Pages in pdfs
Re this: Jc3s5h, how is this controversial? This is simply a technical note about something that is easy to confuse. As long as we have a section about PDF pages in URLs (I don't know if we should, but we currently do), then it certainly makes sense to clarify a plausible misunderstanding. – Uanfala (talk) 20:26, 3 October 2020 (UTC)
- I didn’t think PDF documents were considered reliable in the first place. So easy to fake. Blueboar (talk) 20:44, 3 October 2020 (UTC)
- I refer Blueboar to [1] or perhap the forum section of [2] to discuss the ease of faking PDFs and countermeasures for such faking. For purposes of citing in Wikipedia, I think it is sufficient if the PDF can be downloaded from a reliable source, such as a reputable academic journal website. Jc3s5h (talk) 20:57, 3 October 2020 (UTC)
- (edit conflict)I don't see exactly what you mean, but the two things are orthogonal. Reliability is a feature of a publication, not of the file format in which its publisher has made it available. – Uanfala (talk) 20:58, 3 October 2020 (UTC)
- I have personally been involved in a case where a reliable website unknowingly linked to an altered PDF file of a book, assuming that the PDF was accurate. It was only by comparing the PDF to the original hard copy that the alteration was discovered. I learned that we should ALWAYS find and cite the original, and not a copy found on the internet. Blueboar (talk) 21:08, 3 October 2020 (UTC)
I consider User:Uanfala's edit of the guideline incorrect. To defend my position, lets start with an example from the 17th edition of the Chicago Manual of Style ¶ 14.171. It contains the citation
5. Lina Perkins Wilder, "'My Exion Is Entered': Anatomy, Costume, and Theatrical Knowledge in 2 Henry IV," Rennaissance Drama 41, no 1/2 (Fall 2013): 60, https://doi.org/10.1086/673907.
When one visits that DOI, one finds a PDF which can be downloaded for free. The PDF page numbers (displayed by Adobe Reader near the top of the window, outside the area that displays the text) run from 1 to 28. The citation refers to page 60. If one goes by the page numbers that are part of the display of the text, there is indeed a page 60. So the University of Chicago Press disagrees with Uanfala.
For practical reasons, I also disagree. Sometimes identical versions of a publication are available as PDFs and on paper. If we read it in a PDF, we should certainly say so, in accord with "Citing sources" and other guidelines, but there's no reason to be actively hostile to readers who happen to possess the paper version by making it impossible for them to determine which page one is referring to except by also obtaining the PDF version.
Furthermore, sometimes PDFs are handier to work with in printed form (for example, if one does not possess a dual-monitor computer setup and wishes to refer rapidly back and forth between the document and the contents of a different computer document. But once the document is printed, the PDF page numbers are lost. Jc3s5h (talk) 21:21, 3 October 2020 (UTC)
- Well then, we need to get two things straight here. First, the additions weren't made by me (Uanfala), but by Pol098. I was simply questioning the reversal. Second, the relevant bit of the guidelines is this (Pol098's proposed additions underlined):
- Links to long PDF documents can be made more convenient by taking readers to a specific page with the addition of
#page=n
to the document URL, wheren
is the page number. (This must be the page number shown by the PDF viewer, not the number displayed on the page.) For example, usinghttp://www.domain.com/document.pdf#page=5
as the citation URL displays page five of the document in any PDF viewer that supports this feature. If the viewer or browser does not support it, it will display the first page instead.
- Links to long PDF documents can be made more convenient by taking readers to a specific page with the addition of
- As you can see, this is not about which page to cite (of course no-one is advocating for citing page numbers different from the actual ones in the source text), but about how to format an URL to a specific page in a pdf file. – Uanfala (talk) 21:30, 3 October 2020 (UTC)
Uanfala, I'm sorry I didn't double-check who actually edited the guideline. I'm not clear about what your post at 21:30 UTC means, so I will clarify my understanding of the edit. Here is a screenshot of a part of a PDF document as viewed in Adobe Reader:
As I understand the edit, User:Pol098 is instructing us to cite the page which occupies most of the screenshot as "5" but I contend it should be cited as "iii". Jc3s5h (talk) 21:59, 3 October 2020 (UTC)
- @Jc3s5h: I think you are confusing two different things here. The citation should specify the printed page, using the
|p=
to either{{cite ...}}
,{{citation}}
or{{sfn}}
. The|url=
parameter should use the page of the PDF so that browsers open it in the right place. Whilst I'm here, @Blueboar:, it's not PDFs per se, but anything online. An HTML page is probably easier to alter than a PDF. Martin of Sheffield (talk) 22:15, 3 October 2020 (UTC) - (edit conflict)Of course the page from the screenshort should be cited as "iii", no-one is disputing that. What we're discussing is a paragraph of the guidelines that instructs editors how to format a URL to a PDF page. To use your previous example:
5. Lina Perkins Wilder, "'My Exion Is Entered': Anatomy, Costume, and Theatrical Knowledge in 2 Henry IV," Rennaissance Drama 41, no 1/2 (Fall 2013): 60, https://doi.org/10.1086/673907.
- If you wanted the link to go straight to p. 60 of the PDF file, you will do it by appending
#page=4
to the direct URL: https://www.journals.uchicago.edu/doi/pdf/10.1086/673907#page=4 (whether that link takes you directly to the desired page or not will depend on your viewer). The point is that in the URL you need to give the page as it appears in the PDF file, regardless of which page in the source (or your citation) this will represent. – Uanfala (talk) 22:16, 3 October 2020 (UTC)- I re-read Pol098's version of the page, and, after being prompted by this discussion, see that the passage probably is meant to only be about how to write the URL, not how to write the page number in the citation. However, nowhere does the guideline say that the page that would appear if the PDF were printed is the one that should be cited. Where there is a specific statement about citing the page that appears in the viewing software, and no statement about citing the printed page number, many editors may be nudged in the direction of citing the page number that appears in the viewing software. Jc3s5h (talk) 23:09, 3 October 2020 (UTC)
- User: Martin of Sheffield, this guideline is about citations in general, not necessarily about citing with Wikipedia citation templates. So any language we end up adopting should not specify parameters from those templates. Jc3s5h (talk) 23:12, 3 October 2020 (UTC)
- @Jc3s5h: Clearly. An example on a talk page to illustrate a confusion is not necessarily written in precise legal terms, I leave that to others. I'm a computer specialist not a lawyer so look to the logic and not the regulation. The substantial point though is not to confuse the page in the reference or citation, however formatted or not with the PDF page in the URL. Martin of Sheffield (talk) 08:44, 4 October 2020 (UTC)
- (drive-by comment) I can't easily find an example, but I remember having put parenthetical notes saying e.g., "(page [whatever] of the PDF)" in the page= parameter in some {{cite journal}} cites after the page number printed on the page in the PDF document. Wtmitchell (talk) (earlier Boracay Bill) 10:22, 4 October 2020 (UTC)
- Jc3s5h is right that there doesn't appear to be any advice here on how to cite pages in PDF documents. I think the section could be rewritten to clarify that there may be a discrepancy in page numbers in PDFs, and that you cite the page numbers that appear on the page, and link to the ones that appear in the PDF viewer interface. An alternative would be to drop the whole section. Frankly, how often does such a situation arise? Ideally, we should be linking not straight to the pdf, but to the metadata page for that resource, which will then have the onward link to the file. And also, any competently published PDFs will have their numbering structure match what's visible on the page. – Uanfala (talk) 14:34, 5 October 2020 (UTC)
- I definitely agree that there should be advice. I don't agree that
|url=
is an appropriate place to link to the page. The obvious way to do it is to let|url=
link to the document,|section-url=
link to the chapter and|page=
link to the page, e.g., this[1] reference could be marked up as{{citation|title = 3270 Information Display System Data Stream Programmer's Reference|id = GA23-0059-4|section = Read Modified Command|page = [http://bitsavers.org/pdf/ibm/3270/GA23-0059-4_3270_Data_Stream_Programmers_Reference_Dec88.pdf#page=54 3-13]|url = http://bitsavers.org/pdf/ibm/3270/GA23-0059-4_3270_Data_Stream_Programmers_Reference_Dec88.pdf |section-url = http://bitsavers.org/pdf/ibm/3270/GA23-0059-4_3270_Data_Stream_Programmers_Reference_Dec88.pdf#page=53 |publisher = IBM}}
Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:43, 5 October 2020 (UTC)
References
- ^ "Read Modified Command" (PDF), 3270 Information Display System Data Stream Programmer's Reference (PDF), IBM, p. 3-13, GA23-0059-4
Expand WP:DEADREF
I have been doing RC patrol recently and I've noticed that tons of people seem to, for some reason, think that the official protocol is to simply remove material from articles (sometimes entire sections) because "the link is dead". While WP:DEADREF does mention this as bullet point 6 (the final point in the list), I think it might be better for that section to mention up-front that removing large referenced sections from articles because "the URL didn't load" is not a proper application of policy. I might just go ahead and do it if nobody objects. jp×g 09:45, 5 October 2020 (UTC)
- What specifically would you propose adding? Nikkimaria (talk) 12:15, 5 October 2020 (UTC)
Foreign lang template to throw after a foreign-language reference? (references without citation templates)
Back in ye olde days of Wikipedia, there used to be an unobtrusive template like lang|en lang|fr lang|ru that would just put a smaller font (Ru) or (Fr) after a footnote reference that's in a foreign language, and automatically added the article to some hidden category for such works. I know {{in lang}} exists now, but it's bulky and plain-text and doesn't appear to have any real benefit that isn't to be had by simply writing "In Russian" myself. Any help finding something smaller? I'm working on an article that is almost entirely non-English sources and I'd rather not put "In German", "In French" after each citation. HaltlosePersonalityDisorder (talk) 03:15, 7 October 2020 (UTC)
- There's {{lang}} and {{lang-x}} that might help, but I'm not sure they are exactly what you're after. Martin of Sheffield (talk) 15:30, 7 October 2020 (UTC)
- If you’re using the CS1/2 citation templates, there’s a
|language=
parameter you can use that takes the ISO 639 code; is that what you’re looking for? Umimmak (talk) 16:00, 7 October 2020 (UTC)- In the CS1/2 citation templates, there are also parameters like
|script-title=
which can be prepended with an ISO language code for non-Latin languages, as in|script-title=zh-Hant:瘋狂亞洲富豪
. Furthermore, if there's a Wikipedia article you want to link to where the article in another language is the only one that exists or is more complete than the English Wikipedia article, I use {{ill}}; so for example for the Chinese-language Hong Kong newspaper Ta Kung Pao the Chinese article is more extensive in discussing nuances of its coverage and biases so in citations I fill in|publisher={{ill|Ta Kung Pao|zh|大公報|preserve=1}}
which produces "Ta Kung Pao ". - Finally, for parameters like
|authorlink=
you can fill in a link to a language on a different wiki, you just have to begin it with a colon: for example|authorlink=:id:Daniel Rudi Haryanto
for Daniel Rudi Haryanto , an Indonesian documentary film maker who despite winning international awards currently only has an article on Wikipedia bahasa Indonesia and not English Wikipedia. - p.s. a benefit of using an appropriate language template or parameter that may not be visible in your own browser is that the HTML code is marked up to indicate the language being rendered, which may help other peoples' browsers or screen readers show it properly. --▸₷truthious Ⓑandersnatch◂ 17:16, 7 October 2020 (UTC)
- Umm, no. Do you not see the at the top of the
{{ill}}
documentation? What your example really produces (as far as the cs1|2 templates are concerned) is this:{{ill|Ta Kung Pao|zh|大公報|preserve=1}}
→[[Ta Kung Pao]]<span class="noprint" style="font-size:85%; font-style: normal; "> [[[:zh:大公報|zh]]]</span>
- All of that ends up in the citation's metadata which should only hold (for your example) the publisher's name; no html markup, no wiki markup, just the name.
{{ill}}
may be the template that the OP was thinking about. That, in my opinion is a badly thought out design. We as editors may know what ru, or es, or kl, or sq mean, but it is doubtful that readers know. We are here for the readers and there is no limit on space; use{{in lang}}
so that you can use the IETF language tags and so that readers know what you mean without having to decode the tag.{{in lang|ru|es|kl|sq}}
→ (in Russian, Spanish, Greenlandic, and Albanian)
- —Trappist the monk (talk) 17:41, 7 October 2020 (UTC)
- "We as editors may know what ru, or es, or kl, or sq mean, but it is doubtful that readers know" – agreed, that's why there is {{Interlanguage link info}} to explain it. Martin of Sheffield (talk) 19:17, 7 October 2020 (UTC)
- Umm, no. Do you not see the at the top of the
- In the CS1/2 citation templates, there are also parameters like
Citing a section of a web page?
Transmission of COVID-19 cites https://www.cdc.gov/coronavirus/2019-ncov/faq.html in multiple places. The problem is, the page is hard to navigate, with the collapsed sections. At least in Chrome, if you search on a page for a word in a collapsed section, it won't be found. So, is there some way, analogous to {{rp}}, to cite a specific section on a web page? -- RoySmith (talk) 02:02, 8 October 2020 (UTC)
- @RoySmith:, if you use shortened footnotes ({{sfn}}), you can use
|loc=
instead of|p=
. If you are using {{cite web}}, you can use|at=
instead of|p=
. And if you're hand-rolling the citation, you can use plain text. In any of those cases, I'd just put the closest header title above the section of interest. Naturally, if it's an anchor, then include the fragment in the link. Mathglot (talk) 11:35, 8 October 2020 (UTC) - Here's an example:
- Can wild animals spread the virus?[1]
- Note that in this example, the term '§wild animals' in the short footnote is a direct link to the FAQ question. Hope this helps. Mathglot (talk) 11:48, 8 October 2020 (UTC)
- "Coronavirus (COVID-19) frequently asked questions | CDC". CDC. 18 September 2020.
References
"Work" versus "agency" versus "publisher"
One mistake that I made consistently during my early wiki career was to misuse the "publisher" and "agency" fields for e.g. The New York Times, when what I was looking for was actually the "work" field. "Work" just isn't a very good label. I notice that there's a question mark in the form that displays a clarifying message—perhaps that was added more recently, helping newer editors more than I was, or perhaps it just took me a while to notice because it's so subtle (in which case newer editors are probably going through the same thing). Is there anything we could do to help people learn about these fields more easily? {{u|Sdkb}} talk 19:15, 13 October 2020 (UTC)
- Courtesy ping Maile66, who I notice asked about this at VPT three years ago. {{u|Sdkb}} talk 19:21, 13 October 2020 (UTC)
- There are multiple alternative parameter names for various specific types of works, eg
|website=
or|newspaper=
. Based on your VPT link it seems like the best way to help people learn about these in that specific case would be a change in RefToolbar? Nikkimaria (talk) 20:27, 13 October 2020 (UTC)- Nikkimaria, yeah, I'm thinking primarily about RefToolbar, since really that's the only way any newer editor (using source code) ought to add references. {{u|Sdkb}} talk 21:06, 13 October 2020 (UTC)
- It is probably true that "work" could be confusing new editors who use structured citation helpers. A better label might be "source" since that is what "work" represents, and that is what is cited.
- Nikkimaria, yeah, I'm thinking primarily about RefToolbar, since really that's the only way any newer editor (using source code) ought to add references. {{u|Sdkb}} talk 21:06, 13 October 2020 (UTC)
- There are multiple alternative parameter names for various specific types of works, eg
- In a citation context, "source" is any published, discoverable, free-standing item that unambiguously verifies, or includes subitems that unambiguously verify, in real time, claims (in this case in wikitext), in whole or in part. Sources unrelated to the editor of such claims are preferred, though this is not necessarily a disqualification. Proven past reliability applies only to the related past citations, and no source should be considered a priori reliable (or unreliable) on any subject.
- Good luck! 65.88.88.69 (talk) 21:12, 13 October 2020 (UTC)
- "Source" is ambiguous, since a typical news or journal article has an article title and a publication title. That is probably why
|source=
is not a supported parameter in any of the Citation Style 1 "Cite xxx" templates. "Publication" or "Periodical" might be more helpful than work, although the latter might be too jargony for the average editor. For those of us who do not use RefToolbar, a screen shot or two, showing the placement of this word "work", would be helpful. – Jonesey95 (talk) 21:46, 13 October 2020 (UTC)- You are confusing the source (the journal) with an in-source location (the article). Until a few years ago journal articles were practically non-discoverable by the general public. Many if not all reference databases would index journals, not articles. That was the singular, free-standing, searchable item. Granted that with digital indexing it is easier to zero in on a location rather than to the contents of the including source. But there is no such structured helper in Wikipedia. All of them, whether they are templates or addons are focused on sources (the enclosing works), not in-source locations. So there is no "cite article". The reason a parameter "source" does not exist in one part (or anywhere) of Wikipedia's citation environment has more to do with entrenchment of faulty design and of the attendant (erroneous) terminology than anything else. 135.84.167.61 (talk) 23:04, 13 October 2020 (UTC)
- 1. I am not confused (this time). Journal articles have been discoverable at public libraries for as long as I can remember. I learned how to use an index of periodical articles in the early 1980s as a young student, before there were general-purpose computers in school libraries; here's one from 1922.
- 2. {{Cite journal}} is specifically for citing individual journal articles, and will give an error message if the title of the article is not provided. {{Cite web}} and {{Cite news}} are the same.
- 3. The phrase "in-source location" is used by the Citation Style 1 documentation to refer to a page number or other specific location within the cited item. It would help this discussion if you referred to the documentation before making claims about how templates work and what they are for. – Jonesey95 (talk) 00:22, 14 October 2020 (UTC)
- You are confusing the source (the journal) with an in-source location (the article). Until a few years ago journal articles were practically non-discoverable by the general public. Many if not all reference databases would index journals, not articles. That was the singular, free-standing, searchable item. Granted that with digital indexing it is easier to zero in on a location rather than to the contents of the including source. But there is no such structured helper in Wikipedia. All of them, whether they are templates or addons are focused on sources (the enclosing works), not in-source locations. So there is no "cite article". The reason a parameter "source" does not exist in one part (or anywhere) of Wikipedia's citation environment has more to do with entrenchment of faulty design and of the attendant (erroneous) terminology than anything else. 135.84.167.61 (talk) 23:04, 13 October 2020 (UTC)
- Jonesey95, you can look at GorillaWarfare's video at Wikipedia:RefToolbar/2.0 (or just enable RefToolbar and test it for yourself). When you hover over the question mark near "work", you get the tooltip
Name of journal, magazine, newspaper, periodical or website
, encoded here. {{u|Sdkb}} talk 23:35, 13 October 2020 (UTC)- Thanks. I looked at the video, and at 0:53, the "Cite journal" pop-up box shows "journal" as an option, but I don't see "work". Can you be more specific about how to reproduce the problem that you are experiencing? – Jonesey95 (talk) 00:22, 14 October 2020 (UTC)
- Jonesey95, make sure you have RefToolbar enabled (as is default). Go edit a page in source code, go to the cite tab, and under the templates menu click "cite news". The box that pops up will have a number of fields, including "Work", "Agency", and "Publisher". The discussion here is about the potential confusion among those fields. {{u|Sdkb}} talk 00:49, 14 October 2020 (UTC)
- Thanks. I looked at the video, and at 0:53, the "Cite journal" pop-up box shows "journal" as an option, but I don't see "work". Can you be more specific about how to reproduce the problem that you are experiencing? – Jonesey95 (talk) 00:22, 14 October 2020 (UTC)
- "Source" is ambiguous, since a typical news or journal article has an article title and a publication title. That is probably why