Template talk:Harvard citation

Core update
Given the commonality in markup for the author-date templates, I have developed a meta-template at Harvard citation/core. See Template talk:Sfn. ---— Gadget850 (Ed)  talk 01:40, 9 April 2012 (UTC)

✅ ---— Gadget850 (Ed)  talk 16:46, 28 April 2012 (UTC)

consolidating and abandoning Template:Harvard citation/core
Please see Module_talk:Footnotes.

—Trappist the monk (talk) 16:08, 8 August 2018 (UTC)

Slash instead of whitespace as delimiter (between name and year)
Laws usually get referenced with
 * "number"/"year of resolution" (e.g. the Election Code for Spain: 5/1985) or
 * "year of resolution"/"number" (e.g. the Election Code for Finland: 1998/714) or
 * "abbreviation"/"year of resolution". (e.g. the European Election Law for Germany: EuWG/1978 )

So everytime, we have a slash inside; not a whitespace. Would it be possible to set a parameter that specifies the delimiter (just like ps=...)? Short footnote references to laws look strange if they have a whitespace inside. Thank you in advance! 17:22, 28 February 2019 (UTC) — Preceding unsigned comment added by C-Kobold (talk • contribs)


 * Is there any need for this? Can you show any examples from Wikipedia where such usage is needed?
 * The harv templates can be used in some very odd ways, and undoubtedly can be adapted to a special case like this. It is probably better to do that as needed rather than burden the code with a hardly (or even only hypothetically) used "feature". &diams; J. Johnson (JJ) (talk) 19:08, 28 February 2019 (UTC)

Concerning examples: I am currently working on User:C-Kobold/EU parliament national election systems, where I need a lot of short references to laws. C-Kobold (talk) 20:39, 28 February 2019 (UTC)

If the harv-template is not suited for this purpose, which template can I use instead? C-Kobold (talk) 20:42, 28 February 2019 (UTC)


 * I did not say that the harv templates are "not suited for this purpose". What I said is that they "undoubtedly can be adapted to a special case like this." I suggest we continue this on your Talk page. &diams; J. Johnson (JJ) (talk) 22:08, 28 February 2019 (UTC)

Cosmetic issue: nested quotes.
Not certain this is the proper forum, or whether the footnotes/cs1 module talk pages would be better. Please feel free to move this to the appropriate page. Citations with work titles that display nested quote marks are rendered properly with a non-breaking thin space. However it seems that this does not happen when the citation displays as a tooltip when a pointer hovers over the harvard citation link.
 * In the following example, 12 line breaks were added between the sections to facilitate display of this point:

This is exhibited using Safari 12.1. 72.43.99.138 (talk) 14:20, 7 May 2019 (UTC)
 * The same happens on my win7 w/chrome.  It appears that whatever code it is that renders the tool tip, does not apply css.  I made some tweaks to your  template to show this more clearly.  cs1|2 uses css from Module:Citation/CS1/styles.css to render the access icon for the doi link and to kern quote marks – cs1|2 does not use thin-space characters for kerning; the pdf icon is provided by MediaWiki:Common.css.
 * —Trappist the monk (talk) 15:31, 7 May 2019 (UTC)
 * Well, no, it doesn't apply CSS because it can't. The tooltip is drawn from [//www.w3.org/TR/html5/dom.html#the-title-attribute the  attribute], which can contain only plain unstyled text, delimited either a pair of double quotes or a pair of apostrophes. This in turn means that if the tooltip contains double quotes, you need to use apostrophes as the delimiters, and vice versa. -- Red rose64 &#x1f339; (talk) 16:01, 7 May 2019 (UTC)
 * However, spaces are plaintext, aren't they? It is more likely that the html  attribute ignores trailing spaces. Cs1 css uses 0.2em for kerning, which is the width of thin space. This is not rendered by the tooltip as the trailing whitespace is removed, and then the cs1    argument is rendered accordingly (in this case, in double quotes). I gather this maybe a minor issue, but technically it does not seem insurmountable. The culprit is in tooltip and perhaps the associated module. 65.88.88.75 (talk) 18:21, 7 May 2019 (UTC)
 * I do not think that the culprit is in tooltip. This text has a tool tip.  Nor do I think that the problem has anything to do with a   attribute.  This text has a tool-tip.  Notice how both of these  and   tool tips have similar appearance but are distinctly different from the 'tool-tip' rendered by Reference_Tooltips.
 * —Trappist the monk (talk) 18:43, 7 May 2019 (UTC)
 * You are correct. Guess I should be looking @ the associated MediaWiki javascript and css modules. 65.88.88.75 (talk) 18:56, 7 May 2019 (UTC)
 * Nobody mentioned the template until 18:21, 7 May 2019 (UTC). This template uses [//www.w3.org/TR/html5/text-level-semantics.html#the-abbr-element the  element], the documentation for which states The   attribute may be used to provide an expansion of the abbreviation. The attribute, if specified, must contain an expansion of the abbreviation, and nothing else. - it is a therefore misuse of that element if it is used purely for the purpose of generating a tooltip. The documentation for  cautions against this, several times. -- Red rose64 &#x1f339; (talk) 19:54, 7 May 2019 (UTC)
 * Yes, I know that. I was refuting IP editor's assertion that the culprit is in tooltip.  And yes I know that I did not use it as an abbreviation.  The point was to show that the style of a tool tip rendered using  and the style of a tool tip rendered using a   attribute differ markedly from the tool tips rendered by Reference_Tooltips.
 * —Trappist the monk (talk) 20:07, 7 May 2019 (UTC)

Following a cursory look at MediaWiki:Gadget-ReferenceTooltips.js it seems to me it may be more trouble to fix this than is worth. Several other pieces of extensively used code seem to be involved, but I don't have the time to hunt down exactly how the various CS1 arguments are parsed in order to display as they do. Thank you for your inputs anyway. 72.43.99.138 (talk) 00:53, 8 May 2019 (UTC)
 * ReferenceTooltips doesn't parse CS1 templates - or any templates at all. When you hover over a ref link like the onmouseover event is triggered, which fires the JavaScript in the gadget. The gadget, knowing where it is being invoked from, can follow the link to see what is displayed at the link's destination. It then extracts the appropriate HTML element (and its contents) from that place in the page's HTML source, and displays it inside a balloon. The gadget doesn't know (or care) if the HTML concerned originated with a template, the gadget merely copies the HTML from one place to another. Since it is the page's HTML source that is processed, this occurs a long time after the MediaWiki template parser has finished with the page; furthermore, the gadget operates client-side, and it is highly unlikely that your browser has a MediaWiki template parser built in. -- Red rose64 &#x1f339; (talk) 08:59, 8 May 2019 (UTC)
 * This makes sense, but may not be entirely accurate. It does not explain why the thin space between nested quotes disappears. Is the gadget (or one of the called subroutines, if applicable) stripping it before CS1 formatting, ie before wrapping the field in double quotes? If so, this could indicate that processing returns to CS1. Is there code that removes spaces after quotes/apostrophes regardless of how the field is populated? In that case, would replacing the soft kerning with hard kerning (non-breaking thin space) in CS1 make any difference? As stated, I did not look at the gadget internals at length. 24.105.132.254 (talk) 13:44, 8 May 2019 (UTC)
 * Once again, the gadget works client side. That is, it is your browser that invokes it. All it has to work with is the HTML served by Wikipedia. It cannot send anything back to Wikipedia for further processing. It knows nothing of Wikipedia templates, nor of CS1.
 * Let's consider Choiceless awareness. At the end of the first sentence, there is a little which is a link to a point elsewhere in the page (the first item under Notes, to be exact). This link begins with the HTML tag . When you hover over that link, the ReferenceTooltips gadget extracts the value of the   attribute, i.e.   and examines the page HTML looking for another tag which has that value in its   attribute - this is the destination of that link. It finds a  tag. It then scans from the end of that tag until the closing tag that matches it (in this case, a  tag), copying content to a string. Here it is:   From that it remove any element having the class   - in this case, it's the first  and its contents. Then it draws a balloon at the mouse pointer position, into which it places the remaining portion of the string. -- Red rose64 &#x1f339; (talk) 20:24, 8 May 2019 (UTC)
 * Ok. However, your example concerns the Harvard link which is a more-or-less straightforward rendering, not the target reference. The page you quote is what led me here to begin with, specifically, currently superscripted with id #5. Hovering over that Harvard anchor will bring up the actual reference:  As we have been discussing, the tag  in that reference seems to be ignored. 108.182.15.109 (talk) 00:49, 9 May 2019 (UTC)
 * We're being led up the garden path here. At each step, you disclose only a tiny scrap of the information necessary for us to work out just what problem you are getting, and at each step it seems that the previous step pointed to something that wasn't relevant. You didn't even mention Choiceless awareness (let alone which reference) until I prompted you, which I only managed by looking at the most recent contributions by 24.105.132.254. Changing your IP address every time you post here really does not help. You are clearly experienced, and so I would expect you to have a registered login ID.
 * I can find no evidence that a U+202F space is being added. All that  does is act as a selector for this rule:   That rule is defined in Module:Citation/CS1/styles.css (this omits the   classes of the selectors, since they are added automatically by the style sheet parser). If the rule is wrong, go to Module talk:Citation/CS1/styles.css, which redirects to Help talk:Citation Style 1 (this being a central discussion page for most of the CS1 templates and modules), and raise the issue there.
 * The is added by Module:Citation/CS1, which is one of the modules that underlie . If adding that span is incorrect, it is a matter for the talk page for the module concerned, i.e. Module talk:Citation/CS1, which also redirects to Help talk:Citation Style 1.
 * If the span is correct, but the ReferenceTooltips gadget is not processing it correctly, that is a matter for the talk page of the gadget, which is MediaWiki talk:Gadget-ReferenceTooltips.js; somebody like, who assisted with some of the more recent enhancements, should be able to comment further.
 * Either way, it is nothing to to with how works or how it is used. This is the talk page for discussing improvements to the template, nothing else. -- Red rose64 &#x1f339; (talk) 09:26, 9 May 2019 (UTC)
 * In the OP it was stated that if this was not the right forum, the discussion could be moved to it. The general case was also laid out in the OP example, ie the space between nested quotes disappears when the reference is rendered in a tooltip. The entire discussion (with fits and starts and amendments, as the issue was looked at more closely) flowed from there, because the original query of the general case was complete. There is no need for specific examples; there is nothing more to disclose. Eventually the discussion arrived at a specific tag implementing an attribute in a CS1 module. But this is only the technical illustration of the original verbose query. It does not resolve it. The "padding" in a padding function adds space. Whether you represent it in Unicode, html, or whatever, it should still be just that (assuming that the underlying scripting language is capable and the various routines are written properly). The question remains, and it is still not clear to me now whether the problem lies with CS1 or the mw reference tooltip. It was also mentioned that resolving this may be more trouble that is worth. That's fine too, if that is the case.
 * I will reiterate that this can be moved wherever the proper forum is. There is nothing to be gained by looking at my or anyone's IP address (I completely disregard all user names too). It takes the focus off the argument. What is pertinent is the argument, not us discussing it. It is an approach that makes things simpler. 108.182.15.109 (talk) 12:49, 9 May 2019 (UTC)
 * I need to amend the above: it was pointed out in the discussion that other CS1 elements will not display when the citation is rendered through Reference_Tooltips. An example was the pdf icon, another example is with . In this case, the lock icon associated with the access requirement disappears. So there may be other considerations too (css was mentioned as one, which may be a relevant issue). 108.182.15.109 (talk) 13:14, 9 May 2019 (UTC)
 * Is Reference_Tooltips rendering citation metadata (such as COinS) only?? 108.182.15.109 (talk) 13:32, 9 May 2019 (UTC)
 * Also note that if you manually add a at the end of the field (in the OP example above, at the end of title) this will be rendered properly by Reference_Tooltips. But it will also show as extra space in the citation wikitext. 108.182.15.109 (talk) 14:05, 9 May 2019 (UTC)
 * Additionally, Reference_Tooltips does not render anything outside the citation template, such as the various link-note templates, or any punctuation following CS1 templates. An example where added terminal punctuation may be appropriate would be using quote when the quotation does not/should not include punctuation inside the quote marks. Note the pertinent CS1 template parameter postscript is suppressed when quote is used. 65.88.88.69 (talk) 21:37, 9 May 2019 (UTC)
 * , I requested the change that would fix the cosmetic issue mentioned by the topic starter and also make several icons that are not currently displayed in tooltips displayed. Jack who built the house (talk) 14:04, 10 May 2019 (UTC)
 * -- Red rose64 &#x1f339; (talk) 11:16, 11 May 2019 (UTC)
 * Interesting solution, especially the addition of the parser output class. :) 72.43.99.138 (talk) 15:14, 11 May 2019 (UTC)

Incorrect rendering
Correct rendering
 * results in

1. Incorrect rendering [eg ref anchor uses journal issue month+year]
 * results in

2. Incorrect rendering [eg serial spanning 10 years, en dash rendered in html]
 * results in

3. Incorrect rendering [Author-Title (MLA) style]
 * results in
 * [edit] MLA style short referencing not supported.

Possibly a missing pipe? 72.43.99.138 (talk) 13:44, 17 May 2019 (UTC)
 * Additional strangeness
 * Correct rendering [eg serial spanning 10 years, en dash rendered via template]
 * results in


 * Correct rendering [eg serial spanning 10 years, en dash rendered via glyph]
 * results in


 * 3. Incorrect rendering [eg serial spanning 10 years, truncated range, en dash rendered via template]
 * results in


 * 4. Incorrect rendering [eg serial spanning 10 years, truncated range, en dash rendered via glyph]
 * results in


 * Note MOS:DATERANGE allows the latter truncated range in specific circumstances. 72.43.99.138 (talk) 13:56, 17 May 2019 (UTC)
 * The positional parameter that follows the last author name holds the publication year (not date) or a year range where the elements of the range are separated using an ndash character or (not the html entity  ).  These work:
 * and these work:
 * These do not work properly because Module:Footnotes does not support YYYY–YY ranges (acceptable year format verification is rudimentary):
 * and these do not work because Module:Footnotes and the cs1|2 templates do not accept the html  entity as a separator (cs|2 documented here):
 * We should probably add support for YYYY–YY ranges.
 * —Trappist the monk (talk) 15:06, 17 May 2019 (UTC)
 * So there can be no custom anchors such as ? (using literals to avoid confusion). Btw, the html-rendered en dash should be allowed in ref as it does not emit metadata, correct? 98.0.246.242 (talk) 16:42, 17 May 2019 (UTC)
 * Custom anchors are commonly used when the citation does not have an author but does have some other suitable 'name' (magazines, newspapers, etc):
 * ref is not made part of the citation's metadata.
 * —Trappist the monk (talk) 17:13, 17 May 2019 (UTC)
 * Harvard citations use dates, not just year. A case could be made to rename these templates so they correctly reflect that they use a subset of the Harvard style. The documentation amplifies the misnomer by mentioning "date" a number of times when referring to the relevant parameter. As an aside, since the date/year field will accept a limited set of values, inserted templates whose code may include spaces will be misinterpreted, even if they output year-formatted values. My example would be dash year. This template used to work until recently. And if you examine its source code, it seems a space is causing the recent malfunction.
 * Maybe a relatively recent change at module:Footnotes caused this? 72.43.99.138 (talk) 14:02, 18 May 2019 (UTC)
 * I understand that the above is currently not a good example since it truncates the range, but I believe the main point is still correct. 72.43.99.138 (talk) 14:09, 18 May 2019 (UTC)
 * In no case should either  or  be used. What would happen on 1 January? The reference will not magically alter its publication date, it will still have been published in 2019. -- Red rose64 &#x1f339; (talk) 15:54, 17 May 2019 (UTC)
 * and 2024 (along with the magic word ) were used in examples as variables, for illustration purposes. They should not be taken as parameter values. 98.0.246.242 (talk) 16:29, 17 May 2019 (UTC)
 * Custom anchors are commonly used when the citation does not have an author but does have some other suitable 'name' (magazines, newspapers, etc):
 * ref is not made part of the citation's metadata.
 * —Trappist the monk (talk) 17:13, 17 May 2019 (UTC)
 * Harvard citations use dates, not just year. A case could be made to rename these templates so they correctly reflect that they use a subset of the Harvard style. The documentation amplifies the misnomer by mentioning "date" a number of times when referring to the relevant parameter. As an aside, since the date/year field will accept a limited set of values, inserted templates whose code may include spaces will be misinterpreted, even if they output year-formatted values. My example would be dash year. This template used to work until recently. And if you examine its source code, it seems a space is causing the recent malfunction.
 * Maybe a relatively recent change at module:Footnotes caused this? 72.43.99.138 (talk) 14:02, 18 May 2019 (UTC)
 * I understand that the above is currently not a good example since it truncates the range, but I believe the main point is still correct. 72.43.99.138 (talk) 14:09, 18 May 2019 (UTC)
 * In no case should either  or  be used. What would happen on 1 January? The reference will not magically alter its publication date, it will still have been published in 2019. -- Red rose64 &#x1f339; (talk) 15:54, 17 May 2019 (UTC)
 * and 2024 (along with the magic word ) were used in examples as variables, for illustration purposes. They should not be taken as parameter values. 98.0.246.242 (talk) 16:29, 17 May 2019 (UTC)
 * I understand that the above is currently not a good example since it truncates the range, but I believe the main point is still correct. 72.43.99.138 (talk) 14:09, 18 May 2019 (UTC)
 * In no case should either  or  be used. What would happen on 1 January? The reference will not magically alter its publication date, it will still have been published in 2019. -- Red rose64 &#x1f339; (talk) 15:54, 17 May 2019 (UTC)
 * and 2024 (along with the magic word ) were used in examples as variables, for illustration purposes. They should not be taken as parameter values. 98.0.246.242 (talk) 16:29, 17 May 2019 (UTC)

broken harv link reporting
Please see the discussion at where a broken harv-link reporting scheme is proposed.

—Trappist the monk (talk) 17:46, 16 March 2020 (UTC)

Ref marks
Currently the page reads: "...typically used within tags". This should be changed to reflect the deprecation of parenthical citation from September 2020. I propose changing the "typically" to "always". Mateussf (talk) 03:37, 2 February 2021 (UTC)

Accented author names
The template Harv and its derivatives Harvnb and Sfn seem to always give errors in mobile view when the argument of the "last"-parameter contains an accented character. I have seen this with French and with Irish names. See examples in the citations of Antoine Hamilton and Claude de Mesmes, Comte d'Avaux. With many thanks and best regards, Johannes Schade (talk) 09:55, 15 October 2023 (UTC)
 * I don't think that this is the fault of the template but rather it is caused by MediaWiki writing the anchor wikilink's html differently for desktop and mobile. I've reported the issue at phabricator which see.
 * —Trappist the monk (talk) 15:57, 15 October 2023 (UTC)

Updating documentation
Can we update the documentation to provide the situations where this template is most appropriate to use now that it has been deprecated for body text? Per recent discussions at Help talk:Shortened footnotes and Wikipedia talk:Manual of Style, the parenthetical citations generated by this template are still accepted within explanatory notes. Although harvnb is more common, this template can be placed within ref tags as a shortened footnote. Are there other situations where harv is commonly used and accepted on Wikipedia? Rjjiii (talk) 05:16, 18 March 2024 (UTC)

Discussion at Module talk:Footnotes § loc, at
You are invited to join the discussion at Module talk:Footnotes § loc, at. Rjjiii (talk) 02:44, 4 May 2024 (UTC)