Template talk:Citation/core/Archive 12

Edit request from Nnemo, 26 April 2011 - language
Hello,

See this usage: notes 48 and 49. This is incorrect typography.

Please correct typography. To do so, please put a space between  and the subsequent text.

Thanks,

--Nnemo (talk) 02:27, 26 April 2011 (UTC)
 * ✅ --Philosopher Let us reason together. 03:25, 26 April 2011 (UTC)


 * This is not good. Now there's incorrect typography (extra space where it is not supposed to be) in pretty much all other cases where language param is used. GregorB (talk) 19:29, 26 April 2011 (UTC)
 * Yes, please undo this change until it can be fixed and checked in the sandbox before attempting to deploy it again. I'm seeing things like "Ofman, Yu. (1962), "Об алгоритмической сложности дискретных функций" (in Russian), Doklady Akademii Nauk SSSR 145 (1): 48–51, ." Note the incorrect extra space between the language and the following comma. —David Eppstein (talk) 19:35, 26 April 2011 (UTC)
 * Yes, please undo this change until it's been proved to work and not screw up existing citations. Headbomb {talk / contribs / physics / books} 19:45, 26 April 2011 (UTC)
 * Reverted. Ucucha 19:49, 26 April 2011 (UTC)
 * Thanks. Here is what the problem is: if one omits the title param, a space is missing in certain situations. language is only one of them, there is format too, and the latter was actually not fixed by the requested edit. GregorB (talk) 19:50, 26 April 2011 (UTC)


 * Thanks everyone. The space is still absent in my examples. Nice if some other parameter(s) like  get(s) fixed too.
 * --Nnemo (talk) 21:58, 27 April 2011 (UTC)
 * I've added some testcases that exhibit the problem. Note the challenge here is to fix all problems (both language and format, and quite likely others too), while not breaking anything in the process. This may appear trivial, but I'm not so sure... GregorB (talk) 09:21, 28 April 2011 (UTC)

Request disabled for now. Please reactivate when you have a working version in the sandbox which is ready to copy over. &mdash; Martin (MSGJ · talk) 10:06, 28 April 2011 (UTC)

Separating content from formatting.
Ideally, HTML code should separate semantic content from formatting wherever possible, and leave formatting to style sheets. For example, instead of hard-coding an italicized journal title, the journal title should ideally be wrapped with something like Physical Review D, and then the italicization can be addressed in the stylesheet. Or if someone wanted to portray journal titles in all caps or small caps or underlined, or in a different color, she would be free to use a style sheet that did so. Wrapping article titles in quotation marks could also be done in the style sheet. Further, the issue of whether or not to have bolded volumes would be a matter of user preference. Therefore, I am proposing to add a few css classes to common.css relating to citations, and provide them with default formatting as they exist now. The classes I have in mind, initially, are the following: /* Default styling for the title of any work within a citation, or specifically the title of a periodical: italics */ .citation cite, .citation cite.periodical { font-style: italic; }

/* Default styling for the title of an article within a periodical, or a contribution within a compilation: quotes IE6 and IE7 will show unquoted text */ .citation cite.article, .citation cite.contribution { font-style: normal; } .citation cite.article:before, .citation cite.contribution:before { content: '"' } .citation cite.article:after, .citation cite.contribution:after {     content: '"' }

/* Default styling for a volume number: bold */ .citation .volume { font-weight: bold; } If the css entries are approved in common.css, then it will be a simple matter to amend the template. I have already done testing with a test version of the Citation/core template, and the resulting citations look perfect in Chrome, Firefox, and IE8, and are fine in IE6-7 (IE6-7 can't do the quotation marks, but they are not critical). CO GDEN  05:51, 27 April 2011 (UTC)


 * I didn't study the styling you propose. I support the principle 200 %. It entails a much better accessibility, and Wikipedia has to be accessible.  and   must never be used of course — they are meant to disappear —, but   and   are OK, and can be styled I think.
 * --Nnemo (talk) 22:14, 27 April 2011 (UTC)
 * Great idea. One minor point: those quotation marks shouldn't be curly. Ucucha 22:21, 27 April 2011 (UTC)
 * IE6 (4%) and IE7 (12%) don't support the :before and :after pseudo-elements, so those styles and content will not be applied. See . And yes, those should be straight quotes; they can be changed in personal CSS. ---— Gadget850 (Ed)  talk 22:40, 27 April 2011 (UTC)
 * Noted as to the curly quotes. For IE6 and IE7, the citations will simply show as titles without quotes, which is still a good and very readable citation. Many citation styles don't include the quotation marks anyway. This very minor issue will disappear as users graduate to better browsers.
 * Note that this uses the html "cite" element for all titles, which is exactly what HTML5 specifies, and HTML4 implies. CO GDEN  23:21, 27 April 2011 (UTC)
 * Good on ya! Separating style from substance seems like a long overdue change, but the timing of the introduction may be significant in order to minimize objections amongst those who are greatly concerned with appearance, even on IE6 and 7. In lieu of quotation marks, would underlining be a viable alternative on those browsers? I presume the load times would be at least as good as the existing form of the template - this has been a sore point on some massively-ref'd articles. LeadSongDog come howl!  02:33, 28 April 2011 (UTC)
 * This shouldn't have any measurable effect on load times. I have high hopes for the TemplateAdventures extension eventually fixing that issue. For IE6/7, it would be relatively easy to include a special IE6/7 rule for underlining, but I think the citations look just fine with the quotes simply omitted. CO GDEN  03:59, 1 May 2011 (UTC)
 * Unless there is any objection, I'll be making the change, first at common.css, and then in the template. Most users should not see any change. IE6-7 users will see the quotes disappear from journal titles, so that a journal will look something like this:
 * Gates, Bill (2011), How article titles appear for IE6 and IE7 users only, Journal of Half-Assed Browsers 12 (2): 1-8.
 * CO GDEN  16:22, 2 May 2011 (UTC)

Once again, should volumes be bold?
This has been brought up before, but never really resolved. Volume numbers are presently bolded,which was a random choice probably made by me many years ago. But most style guides do not bold their volume numbers, and bolding does not seem necessary here to distinguish the volume from other numbers. Therefore, I think that we ought to just leave off the unnecessary bolding for volume numbers. As discussed above, I am in the process of making semantic html classes for parts of the citation that might need special formatting, and I still plan to wrap the volume number in an html class, so that if anybody is really attached to bold volumes, they can add to their personal css style sheet the line. If people really still want bolding, I could add this line to MediaWiki:common.css as well, but I'm thinking that maybe a large fraction of editors would rather not have bolding, but are accepting it because it's not that big of a deal. CO GDEN  01:00, 13 May 2011 (UTC)
 * Let's keep it like it is currently. Rjwilmsi  07:28, 19 May 2011 (UTC)
 * Thank you for your vote. Hans Adler 11:17, 19 May 2011 (UTC)
 * I agree. In some cases I have actually added the volume number to the title because the bolding jumps out of the page. It's just about the last thing that we should draw attention to. Hans Adler 11:17, 19 May 2011 (UTC)
 * In the 2007 edition of Citing Medicine they've dropped the bolding of volume numbers, and indeed say more generally: "Use caution when employing typography, such as bold type and italics, to indicate parts of a journal article citation. Too many variations in type styles may actually make the reference harder to read." This seems consistent with the whole idea that format and data should be decoupled to be robust under the transformations wrought in reusing content. Bolding is easily lost in copying, scanning, faxing, etc. LeadSongDog come howl!  19:35, 19 May 2011 (UTC)
 * Maybe my comment was misunderstood. I think we should keep the existing bolding in the CSS default. I'm expecting any use of extensions or CSS for citation templates to maintain the existing formatting. Rjwilmsi  20:20, 19 May 2011 (UTC)
 * @Rjwilmsi, Could you please explain your reasoning? To maintain a styling that goes against the prevailing academic practice, there ought to be a clearly identifiable reason why we should do things differently than the rest of academia. CO GDEN  06:41, 20 May 2011 (UTC)
 * That's not quite what Rj said. He's right that the technical change should not drive the style change. If we want to get rid of the bolding, it should happen right away in the existing template with a trivial change. Conflating it with the CSS introduction risks creating opposition to the tech change solely on style concerns. However, this is not the right page to discuss changes to MOS. Style changes should have much broader agreement than just the watchers of this template.LeadSongDog come howl!  13:06, 20 May 2011 (UTC)
 * Looking at the code for present implementation, does the wrapping of the Volume in nowiki/ nowiki/ tags make sense to anyone? Other parameters are wrapped in nowiki nowiki/ as one would expect.LeadSongDog come howl!  13:35, 20 May 2011 (UTC)
 * Assume you mean the use of - these are present so that the bolding may be turned off by placing wiki markup in the parameter; that is,  123  will display correctly as  123  instead of '123' which is what would show if the  were absent. -- Red rose64 (talk) 13:51, 20 May 2011 (UTC)
 * I've never seen the "nowiki /" closing tag used without a preceding "nowiki" tag to open it. If it is unary, what specifies its range of action? So much to learn... LeadSongDog come howl!  17:01, 20 May 2011 (UTC)
 * It separates the pieces before and after it. For example,  produces ' ', but   will make the following text italic. Ucucha 17:26, 20 May 2011 (UTC)
 * (Hits self with cluestick) Ah, Thank you. LeadSongDog come howl!  18:35, 20 May 2011 (UTC)
 * isn't a closing tag... the closing tag for is  - the position of the slash relative to the tag name is the significant factor.  is a single (or self-closing) tag - it's a contraction of, and is exactly equivalent to, an empty  pair. As Ucucha states, it's there as a separator. The fact that in this template it's coded as   is irrelevant - it could be coded using almost any self-closing tag valid in MediaWiki, such as : for example, whereas   shows as '123',   shows as  123 . Obviously, self-closing tags that by their very presence cause something to happen, such as  or, cannot be used for such a purpose. -- Red rose64 (talk) 12:49, 21 May 2011 (UTC)
 * I agree with LeadSongDog in that bolding or not is a non-trivial MOS change, not a technical one, so needs much wider discussion if a change is proposed. The immediate remit here is about a technical change, so should not involve a style change. Rjwilmsi  01:08, 21 May 2011 (UTC)

Request to add DeadURL parameter
Per Requests for comment/Dead url parameter for citations, could the following change please be made: Sandbox Source.

It basically does this: A different display for when no is set – main link will be IncludedWorkURL and the archive text will lead to the ArchiveURL (see RfC or sandbox below for preview). I would not mind the template regulars checking the mark-up, as this is first I've fiddled with /core source.

Here are all the test cases I could think of: User:H3llkn0wz/Sandbox3 (currently limited to Cite web in actual sandbox implementation, but showing all that use it to make sure nothing breaks; note that post-expand size is too big there).

Afterwards, a change like this will be required for all templates that use archive parameters, but I will file that separately on corresponding talk pages. Nothing should change/break without those. — HELL KNOWZ  ▎TALK 08:06, 10 June 2011 (UTC)
 * Made a tiny tweak, but your testing seems very thorough. Nice work! &mdash; Martin (MSGJ · talk) 13:03, 10 June 2011 (UTC)

PMC URL generation discussion
Editors here may be interested in Template_talk:Cite_journal. Thanks Rjwilmsi  14:42, 12 June 2011 (UTC)

authorlink parameter
What is the correct usage of Authorlink# parameters? When should the field be piped and when should the authorlink be used? I raise this because I thought author and editor fields do not get linked directly to produce metadata and parsable data for external bibliographical tools. Citation/core currently produces COinS, and any wikilink gets incorrectly encoded together with the author/editor name. I understand the starting and trailing square brackets can the trimmed with string functions to produce the correct output? Can this be done with piped links as well? Would the template not become overly complex?

So the two basic cases:
 * Should  be converted to  ?
 * Should  be converted to  ? —  HELL KNOWZ  ▎TALK 10:13, 15 June 2011 (UTC)


 * Yes to both. Per the docs, the authorlink field, if used, should contain the title of an existing Wikipedia article about the first author. Wtmitchell (talk) (earlier Boracay Bill) 10:34, 15 June 2011 (UTC)
 * There is currently a bot going around fixing up authors linked improperly, . -- Red rose64 (talk) 13:11, 15 June 2011 (UTC)
 * Yes, my bot, hence the question above. I assumed this was warranted, but I've received comments suggesting difference in opinion. — HELL KNOWZ  ▎TALK 13:24, 15 June 2011 (UTC)


 * You can't use author with Harvard references and you can't use links in lastn or firstn. ---— Gadget850 (Ed)  talk 13:51, 15 June 2011 (UTC)
 * Whether Wolmar, Christian is used or Wolmar, ChristianChristian Wolmar is used, the page as rendered is identical - it's only the COinS metadata that differs. If your browser has a "view page source" function (most do, but the method for accessing it varies considerably), try viewing the source for a page containing a citation.
 * Search for ' ' - that is the start of the COinS for a citation. Much of it is cryptic; what you're looking for are the bits beginning ' '. Each of these extends to the next ' ', and there may be more than one of them if there are multiple authors (there will also be ' ' and possibly also ' ' too, but a problem in these will also show up in the ' '). In this case, prior to the bot edit, we have:
 * Here, the  are the opening square brackets; the two   represent spaces, the   is the pipe symbol, the   is a comma and the   are the closing square brackets, so it is essentially the same as   - clearly the wiki markup is getting included. Compare the same piece of COinS following the bot edit:
 * - the  is a comma and a space as before, but that is permitted: the important thing is that it's free from Wiki markup.
 * It has long been stated on the doc pages for etc. that authors shouldn't be wikilinked, and that the authorlink parameter exists for this purpose. So to my mind, bot edits like the one which I linked above are entirely correct. -- Red rose64 (talk) 14:08, 15 June 2011 (UTC)
 * Not sure if you explained in general or to me specifically, since your indentation is to my comment, but this is largely my reasoning as well. See User_talk:H3llBot. — HELL KNOWZ  ▎TALK 16:16, 15 June 2011 (UTC)
 * I didn't go looking for previous discussions like that mainly because you hadn't linked to any. But I now see that I'm explaining something you already knew! Ah well... but to return to the original point: yes, whenever you encounter a wikilinked author, whether piped or not, it's always best to set up a suitable authorlink instead. As regards Gadget850's comment about Harvard linking - such linking usually relies on the author being split into lastfirst - but you can still use authorlink in conjunction with these. So the ideal alterations would be:
 * From  to
 * From  to
 * -- Red rose64 (talk) 16:38, 15 June 2011 (UTC)
 * Overall no problem. Separation of linking into authorlink is correct and appropriate. I would have commented in favour of the bot task had it not been approved so quickly (not a complaint at all). However, moving from author to last etc. might potentially draw complaint since author/last is arguably a style choice when not using Harv/sfn (not particularly my opinion, might be of other editors). It might be better to stick to author/last whichever is the current use of the citation. Rjwilmsi  17:17, 15 June 2011 (UTC)
 * Not really a style as it gives the same output. It is under the hood— perhaps we should refer to this as markup style, which is relatively unimportant, although consistency is good. ---— Gadget850 (Ed)  talk 18:59, 15 June 2011 (UTC)
 * Overall no problem. Separation of linking into authorlink is correct and appropriate. I would have commented in favour of the bot task had it not been approved so quickly (not a complaint at all). However, moving from author to last etc. might potentially draw complaint since author/last is arguably a style choice when not using Harv/sfn (not particularly my opinion, might be of other editors). It might be better to stick to author/last whichever is the current use of the citation. Rjwilmsi  17:17, 15 June 2011 (UTC)
 * Not really a style as it gives the same output. It is under the hood— perhaps we should refer to this as markup style, which is relatively unimportant, although consistency is good. ---— Gadget850 (Ed)  talk 18:59, 15 June 2011 (UTC)

I am the editor who raised this with H3llkn0wz. It seems from what all you lot have said above that I was mistaken and that one should use the "authorlink" parameter even when the text is identical. I don't think many people are aware of this, and it seems counterintuitive and hence unlikely to be widely followed. I feel this is just making life yet more complicated, for the sake of something the ordinary reader doesn't see. I have yet to come across a convincing explanation of the significance of COinS metadata, or why it matters to anyone other than ubergeeks. -- Alarics (talk) 12:39, 16 June 2011 (UTC)
 * While the utility of COinS is not always obvious, particularly to IE users, it is nonetheless real. Have a look at, and  for more background.LeadSongDog  come howl!  18:35, 16 June 2011 (UTC)
 * Those documents are no doubt all very interesting to the cognoscenti who are on that sort of wavelength, but none of it means anything to me. I have no idea what they are talking about. Where does it say in ordinary English what use any of this is to ordinary Wikipedia users? -- Alarics (talk) 21:21, 16 June 2011 (UTC)
 * I don't think it does; and I don't think it's supposed to, either. The COinS metadata is not there for Wikipedia's own benefit, but is for the benefit of search engines and similar tools, outside of Wikipedia. For example, some browsers may offer plugins which, upon displaying a web page containing COinS metadata, will utilise it in a form which enables a library search to be performed, see here.
 * These processors will be looking for authors written as unambiguous plain text, like "Smith, John" or "John Smith", possibly split into forename/lastname; but they will not be looking for authors containing Wiki markup, like " Smith, John " - the square brackets and pipe will probably confuse them. Even if these characters are filtered out, they'll still encounter the curious-looking "John SmithSmith, John". A bit like Slartibartfast assuming that the Earthman's name is "Dentarthurdent". -- Red rose64 (talk) 13:40, 17 June 2011 (UTC)

TransQuote parameter
Is there any interest in adding a TransQuote parameter to this template, similar to TransTitle but for the quote field? (Presumably implemented as trans_quote in end-purpose templates.) This would provide a standard place to keep the quote translation called for by WP:NONENG; there isn't one currently. —chaos5023 (talk) 05:17, 23 July 2011 (UTC)

Format
The format field seems oddly placed, before the title field:

As best I recall, it used to come after the title, but regardless before is just confusing. ---— Gadget850 (Ed)  talk 02:56, 19 September 2011 (UTC)

Upon reflection, then this would render oddly with TitleType, which is also placed after the title field:

---— Gadget850 (Ed)  talk 03:00, 19 September 2011 (UTC)

Citation class
Citation class is not documented, and I would like to add it. I looked through the archives, but I find little on the intent and nothing on rules. Is there anything that actually uses the class? Are there any rules, other than it has to be one word? ---— Gadget850 (Ed)  talk 11:55, 15 October 2011 (UTC)
 * What is it for and is it already in the template? If it's already in the template, of course it should be added to the documentation... --Philosopher Let us reason together. 13:03, 15 October 2011 (UTC)
 * Yes, it's already in the template, and Citation class is a synonym for Citation type. Various values are passed from the wrapper templates; for example, passes book and  passes Journal. The direct effect is to modify the  element that encloses the whole citation, from  to, etc. -- Red rose64 (talk) 14:25, 15 October 2011 (UTC)
 * In that case, I suspect it should be documented both here and at citation. Here, for editors of the wrapper templates and at citation so they can use it if they aren't (for whatever reason) using one of the wrapper templates. --Philosopher Let us reason together. 14:39, 15 October 2011 (UTC)
 * citation isn't passing this parameter. All of the Citation Style 1 templates pass Citation class; the only one that I ever saw use the alias Citation type I changed in an update to be consistent. All of the CS1 templates use lower case except cite journal. As to what it is used for, I don't really know. ---—  Gadget850 (Ed)  talk 15:22, 15 October 2011 (UTC)
 * They haven't all been changed - certainly passes Journal -- Red rose64 (talk) 15:28, 15 October 2011 (UTC)
 * I don't think it should be documented on - that template (which like  etc. is also a wrapper for ) doesn't pass any value in through either Citation class or Citation type. Unrecognised parameters shouldn't be documented, at least, not in a way that suggests that they are currently valid. If mentioned at all in documentation, it should only be done if the parameter has been valid at some point in the past, and then should be in the form of a note stating that the parameter is now deprecated. -- Red rose64 (talk) 15:25, 15 October 2011 (UTC)
 * Let's strike my earlier comments, then. I guess I misunderstood how this parameter worked.  --Philosopher Let us reason together. 17:12, 15 October 2011 (UTC)

I added the parameter; edit as needed. Looks like we don't have guidelines on use or naming. ---— Gadget850 (Ed)  talk 20:28, 15 October 2011 (UTC)